Cała dyskusja o następcy C nie ma sensu, jeżeli nie ma się ściśle określonych wymagań. A w szczególności jednym z tych wymagań powinno być sprecyzowanie zastosowania, bo być może nie potrzebujemy jednego języka, a kilku.
Istnieją też problemy, które spowalniają adopcję nowych języków programowania w zastosowaniach systemowych. Wymienię tylko dwa.
Problem Legacy kodu. Jest przecież mnóstwo kodu niskopoziomowego, który rozwiązuje konkretne, wbrew pozorom trudne, problemy. Przepisanie takiej bazy kodu do języka nowego może spowodować nowe ukryte błędy. Łączenie kodu nowego i starego może być jakimś rozwiązanie, ale ogranicza/upośledza "bezpieczne" mechanizmy nowego języka. Przepisanie kodu kosztuje. Wyszkolenie programistów by efektywnie używali nowego języka też kosztuje. Utrzymanie starego kodu oczywiście też. Klasyczny problem - inwestować w poprawę starego ale stabilnego rozwiązania czy przepisać wszystko od nowa, licząc na to, że po drodze nie popełnimy błędów. Kiedy przepisywać? Kiedy zostawiać? Nie ma uniwersalnej odpowiedzi, ale mam wrażenie, że w praktyce częściej zostawia się to co już działa.
Problem długoterminowego wsparcia. Niskopoziomowy język programowania ogólnego przeznaczenia wymaga wsparcia, ciągłego portowania na nowe platformy sprzętowe (choćby po to by wykorzystać nowe instrukcje, potrafić zoptymalizować kod pod daną architekturę a także naprawiać błędy, które mogą być w kompilatorze). Wsparcia, za które ktoś musi zapłacić. Takie wsparcie zapewniają zazwyczaj programiści zatrudnieni przez dostawcę sprzętu. To oni pracują nad backendem kompilatora odpowiedzialnym za generowanie kodu maszynowego.
Ostatnio mamy wysyp nowych języków programowania, które próbują coś naprawić, unowocześnić, zrobić inaczej. Pół biedy, gdy infrastruktura kompilatora nowego języka jest wspólna z już istniejącymi rozwiązaniami (gcc, llvm), ale nie do końca rozwiązuje to wszystkie problemy. Przykładowo - generując kod pośredni llvma trzeba wiedzieć pewne rzeczy o platformie docelowej (llvm IR nie jest niezależny od platformy!). Napisanie własnego kompilatora od zera może spowodować ograniczenie adopcji, bo jak przekonać vendorów, by pomogli? Można się spierać, że obecnie liczba platform sprzętowych jest ograniczona, ale nawet ta ograniczona liczba platform do wsparcia może sprawić niemały problem.
Jaką mamy pewność, że język nie podupadnie? Jak to wpłynie na naszą bazę kodu, którą być może trzeba będzie utrzymywać jeszcze przez lata? Kto jest gwarantem stabilnego rozwoju języka? Firmy nie są skore do eksperymentowania na szeroką skalę w kodzie, który ma im zapewnić przypływ gotówki na lata.
Rozwiązanie tylko tych dwóch problemów, nie opisanych w tym poście wyczerpująco, wymaga zainwestowania ogromnych środków finansowych i kadrowych. I nagle okazuje się, że stworzenie nowego język programowania nie jest najtrudniejszym problemem do rozwiązania. A wysyp nowych języków, pretendujących do bycia tym standardowym, nie ułatwia.
Ja bardzo kibicuję nowym językom programowania, śledzę nowości, eksperymentuję z nimi. Ale nie wierzę, by coś zbyt szybko uległo zmianie. Zbyt dużo niepewności i starego kodu, a także kosztów, które już zostały poniesione. Myślę, że C może jeszcze bardzo długo nie doczekać się powszechnie uznawanego następcy, a adopcja nowych języków w tym obszarze będzie bardzo powolna, chyba, że ktoś zainwestuje miliardy dolarów w przyśpieszenie owego procesu.
