CTO Microsoftu odradza korzystanie z C i C++, proponuje coś innego

Jeśli przyjrzymy się dzisiejszej działalności Microsoftu, to łatwo zauważyć, że korporacja ta stoi solidnie, bo na czterech nogach: usługach chmurowych Azure, pakiecie Office, systemie Windows oraz konsolach Xbox.

Kolejność jest nieprzypadkowa – właśnie w takiej poszczególne odnóża przynoszą Microsoftowi największe przychody. Warto zweryfikować dość rozpowszechnione wśród uczestników rynku konsumenckiego przekonanie, że Microsoft to przede wszystkim producent Windowsa.

Azure bazuje (choć według niektórych, np. twórców oprogramowania bazodanowego MongoDB, trafniejsze byłoby słowo „pasożytuje”) w dużej mierze na otwartym oprogramowaniu rozwijanym poza korporacją, Xbox zaś stoi sprzętem, kolejnymi przejęciami, jak to Bethesdy czy Activision Blizzard, i ofertą handlową w postaci usługi Game Pass. 

Kod w Microsofcie

Office i Windows pozostają zatem jedynymi filarami Microsoftu, o którym bez większych wątpliwości można powiedzieć, że są oprogramowaniem spieniężanym w relatywnie tradycyjnym modelu – jako licencja lub usługa. I że to stojący za tym oprogramowaniem autorski i niejawny kod decyduje o konkurencyjności obu programów. W konsekwencji także o tym, że w 2019 roku Microsoft stał się trzecią w historii nowojorskiej giełdy spółką wycenioną na ponad bilion dolarów. 

Nawiasem mówiąc, dwa lata później, w dużej mierze za sprawą spowodowanego pandemią gigantycznego wzrostu zainteresowania komunikatorami Teams i Skype oraz sprzedaży pecetów z Windowsem na potrzeby zdalnej pracy i edukacji, Microsoft warty był już ponad 2 biliony dolarów.

Zarówno Windows, jak i Office w zdecydowanej większości od dekad rozwijane są z użyciem dwóch języków programowania: C i C++. Tajemnicą poliszynela jest jednak, że duet ten to w ostatnich latach gorący kartofel w rękach Microsoftu. Nikt chyba jednak nie spodziewał się tak kategorycznej wypowiedzi, jak ta, której udzielił CTO departamentu Microsoft Azure, Mark Russinovich. Według niego C i C++ to dzisiaj języki przestarzałe i branża powinna ustalić, że nie należy już z ich użyciem rozpoczynać nowych przedsięwzięć.

Speaking of languages, it's time to halt starting any new projects in C/C++ and use Rust for those scenarios where a non-GC language is required. For the sake of security and reliability. the industry should declare those languages as deprecated.

— Mark Russinovich (@markrussinovich) September 19, 2022

CTO Azure chce końca C i C++ 

Mocne słowa, jak na dyrektora technicznego w korporacji, która swoją zdobywaną od ponad 40 lat pozycję zawdzięcza w bardzo dużej części właśnie oprogramowaniu napisanemu w C i C++. Porównanie ich do gorącego kartofla budzi jednak mniejsza zaskoczenie, jeśli śledzi się skrupulatnie blogowe wpisy publikowane przez przedstawicieli Microsoft Security Response Center.

Tam od wielu lat trwa kampania na rzecz intensyfikacji poszukiwań języka, który mógłby z jednej strony zastąpić C i C++, a z drugiej nie powielał komplikacji wynikających z ich używania. Jak bowiem oszacowali pracownicy MSRC, do 70% podatności w produkowanym w Redmond kodzie wynika z błędów w obsłudze pamięci, a te z kolei mają być powodowane niedostatkami C/C++. 

To stanowisko powiela Russinovich, rozszerzając je o opinię, że C i C++ to języki nieprzystające do dzisiejszych realiów i potrzeb. Uważa, że konieczne jest ogólnobranżowe porozumienie o globalnej skali, aby w przypadku nowych projektów C i C++ nie były już w ogóle wykorzystywane. W czasach, gdy korporacje odnoszą trudne do oszacowania szkody finansowe wynikające z incydentów związanych z cyberbezpieczeństwem, dalsza podróż drogą C i C++ jest według niego zgubna. Ma to być opóźnianiem tego, co i tak jest nie do uniknięcia.

Od słów do czynów

Uniknąć według Russinovicha nie da się zastąpienia zasłużonego duetu czymś nowym. CTO Azure wie już nawet, czym. Nie ma zaskoczeń i znów jest to powtórzenie opinii od wielu miesięcy panujących w Microsoft Security Response Center. Wszędzie tam, gdzie nie zachodzi konieczność wykorzystywania garbage collectorów, C i C++ można zastąpić Rustem. Jego efektywność w porównaniu z wykorzystującym odśmiecanie pamięci Go ma być na tyle satysfakcjonująca, że w Ruście powinno się od teraz pisać każdy niskopoziomowy kod.

Takie postulaty nie są oczywiście nowe. Trwają eksperymenty z przepisywaniem na Rusta starszych modułów Windowsa. Ale Russinovich nie poprzestaje na powielaniu spostrzeżeń, ale również wzywa do działania. W myśl: oczywiście, w najbliższej przyszłości nie ma mowy o masowym przepisywaniu kodu w C i C++ na Rusta, ale przecież możemy się umówić, aby niepotrzebnie nie zwiększać jego ilości. Tego rodzaju umowa ponad podziałami rzeczywiście mogłaby coś w IT zmienić.

Takie propozycje padają niemal w przeddzień wydania kolejnej wersji Linuksa, wobec którego Torvalds rozwiał niedawno ostatnie wątpliwości: to Linux w wersji 6.1 będzie pierwszym, w którym do mainline’u trafi kod napisany w języku Rust. Widać zatem, że autorzy powtarzanych od miesięcy deklaracji o popularyzacji Rusta w niskopoziomowym kodzie przechodzą od słów do czynów.