Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Czy naprawdę potrzebna nam alternatywa dla C?

Erik Engheim Principal Consultant / Sixty North AS
Sprawdź, czy potrzebujemy alternatywy dla języka C i jeśli tak, to czym można go zastąpić.

Język C, pomimo tego, że powstał w 1972, nadal jest jednym z najpopularniejszych języków programowania. Patrząc jednak przez pryzmat dzisiejszych standardów, ma on niestety kilka wad i narzuca trochę ograniczeń. 


Indeks popularności języków programowania 2020 od TIOBE 


Można powiedzieć, że te wady i ograniczenia sprawiają, iż C wypadałoby zastąpić czymś bardziej aktualnym. Istnieje obecnie zbyt wiele istotnych programów napisanych w C/C++, których negatywne działanie może spowodować daleko idące konsekwencje (weźmy tutaj na przykład błędy w takich bibliotekach jak OpenSSL). Co więcej, C nie jest zbyt mocny w identyfikowaniu niektórych problemów dotyczących np. przepełnienia bufora. 

Programując w C, zdecydowanie zbyt łatwo jest sobie strzelić w stopę. 

W moich ustach może to jednak brzmieć dziwnie, bo sam jestem fanem dynamicznych języków programowania. Ale problemem jest tutaj type safety. Python, czy Julia, potrafią wyłapać nieprawidłowe użycie typów takie jak np. używanie liczby całkowitej w instrukcji warunkowej. Języki dynamiczne mogą nie wyłapać jakiegoś problemu podczas kompilacji, ale jeśli mają silne typowanie, to wiele z nich są w stanie wyłapać w czasie uruchomienia.  

Ma to duże znaczenie jeśli chodzi o bezpieczeństwo. Wiele luk w zabezpieczeniach powoduje niezdefiniowane zachowania, zamiast kontrolowanego zamknięcia serwera. 

No ale jeśli C jest taki do kitu, to dlaczego nikt jeszcze nie wymyślił pasującej alternatywy? Można to wytłumaczyć na kilka sposobów, chociaż istnieją już w pewnym sensie alternatywne technologie - Java, C#, C++ i wiele innych służą do wykonywania zadań, które wcześniej robiliśmy w C. 

Więc chodzi tutaj bardziej o software, w którym C dominuje:

  • Kernele systemów operacyjnych, np. w Linuksie
  • Mikrokontrolery 
  • Kodeki wideo
  • Współdzielone biblioteki niskopoziomowe, np. OpenSSL
  • Uniksowe wiersze poleceń, np. Is, cat i git


Dlaczego C nadal jest w tych obszarach dominujący? Ponieważ alternatywy nie spełniały naszych oczekiwań. Wiele języków z lat 90. (Java, C#, VB.NET, czy F#) skupiały się na byciu technologiami zarządzanymi przez garbage collection. Nie brzmi to jak dobre rozwiązanie dla powyższych rzeczy.

Potem mamy takie języki, jak Perl, Python, Ruby i JavaScript, i tutaj też żaden nie będzie odpowiedni. Mieliśmy statycznie typowane języki, takie jak Ada, Modula-2 itd. Nie starały się one jednak dopasować do zakresu umiejętności, jakie wtedy posiadano, albo można je było łatwo wykorzystać z obecnymi wtedy bibliotekami C. 

Istniały też takie języki jak D, ale były równie złożone jak C++, co nie było zbyt atrakcyjne dla programistów języka C. Co więcej, D również wymagał na początku odśmiecania, co sprawia, że nie będzie on pasował do wyżej wymienionych zadań. 

Generalnie nie chcemy, aby garbage collector włączał się, gdy chcemy utrzymać określoną liczbę klatek na sekundę. 


Potencjał Go i Rusta

Myślę, że wyraźnym znakiem tego, że potrzebujemy dobrej alternatywy dla C i C++, jest rosnąca popularność Go i Rusta. Istnieje wiele narzędzi, które kiedyś były powszechnie pisanie w C oraz C++, a teraz pisze się je w Go i Rust. Pojawiło się też dużo narzędzi do obsługi wiersza poleceń, które są napisane w tych właśnie językach. 

Kilka z nich opisałem tutaj. Można tutaj zauważyć, że ludzie piszą silniki do gier komputerowych w Rust. 


LLVM, czyli brakujący element

Duży potencjał dla powstania zastępstwa dla C istnieje dzięki dojrzałości kompilatora LLVM. Rozwiązano dzięki niemu część problemów związanych z generowaniem wysoce wydajnego kodu i obsługi wielu platform. Sprawia to, że development jest o wiele bardziej przystępny. 

Zarówno Go, jak i Rust dostarczyły trochę pomysłów co do tego, jak można by na nowo podejść do pewnych rzeczy związanych z C/C++. Pojawia się już nawet trochę możliwych alternatyw dla C:

  • Zig, o którym już kiedyś pisałem tutaj i tutaj.
  • Odin, alternatywa dla C, która jest mocno podobna do Go
  • V language to kolejny język podobny do C, w którym widać wyraźnie inspirację Go i Rustem


Czym może być alternatywa dla języka C?

Język taki musiałby pasować do tych obszarów, w których język C cały czas dominuje. To dlatego nie wszystkie języki będą tutaj odpowiednie. Te, które wymieniliśmy powyżej, mają jednak pewne cechy wspólne, które powinny pasować.

  • Obecnych bibliotek można z łatwością używać ponownie. Ada i Modula-2 poległy, ponieważ nie można ich było efektywnie używać w ekosystemie C (który jest duży)
  • Powinien być stworzony na podstawie konkretnej wiedzy i ustalonej konwencji. Go było w miarę oczywistym kandydatem, ponieważ, pomimo zmian syntaktycznych, API oraz sposób kodowania były podobne do tego, jak się to robi w C
  • Brak odśmiecania lub ręcznego zarządzania pamięcią. C dominuje w obszarach, w których potrzeba nam ścisłej kontroli zużycia pamięci. Garbage collection nie jest tutaj zbyt pomocny - to właśnie stanęło na drodze Go w całkowitym zastąpieniu C
  • Małe binarki. Podobnie do C, Zig pozwala na tworzenie naprawdę małych binarek. Jeśli chcesz osadzić w przestrzeni inny język, to Go tutaj odpada - jego binarki są po prostu za duże
  • Przyjazny dla programowania systemowego. Czasem trzeba manipulować bitami i bajtami. Potrzebujesz dobrych operatorów binarnych i wskaźników. W Javie używanie wskaźników właściwie równa się głośnemu przeklinaniu, ale Go sprawiło, że nie są już tematem tabu
  • Stopniowe zastępowanie kodu C. Czyli mocna kompatybilność binarek z C.


Rozwińmy trochę ostatni punkt. Nikt nie chce nawet próbować zastąpić obecnej infrastruktury C, jeśli oznacza to przepisywanie całego programu za jednym podejściem. Przejście z Objective-C do Swift było takie proste m.in. dlatego, że mogłem przepisywać program po jednej metodzie oraz rekompilować i na spokojnie testować. W takich językach jak Zig też możesz to z łatwością zrobić. 


Podsumowanie

Istnieje wiele powodów, dla których powinno się zastąpić C. A nie zrobiono tego jeszcze, ponieważ nikt się na tym nie skupił i nie było do tego odpowiednich narzędzi. 

Nie jest to jedna z tych sytuacji, w których duża organizacja decyduje za wszystkich - każdy członek społeczności ma tutaj coś do powiedzenia. Warto jednak dodać, że mając LLVM i Go jako inspiracje, stworzenie takiej alternatywy jest dzisiaj bardzo prawdopodobne. 

Moim zdaniem to długi proces i nie ma jeszcze zwycięzcy, a duże organizacje nie przerzucą się nagle na Zig, Odin albo V, dopóki nie sprecyzujemy wyraźnej alternatywy. 

Ale co mamy w ogóle na myśli, mówiąc o zastępowaniu C? COBOL nadal przydaje się w transakcjach finansowych, ale można powiedzieć, że udało się go zastąpić czymś innym, bo nikt go już świadomie nie wybierze do projektu. Jeśli jest to możliwe, to ludzie starają się od niego odchodzić. 

Dużo kodu C nie zostanie przepisane. Po prostu będzie istniał. Możemy jednak dotrzeć do momentu, w którym wybierzemy inny język, niż C, dla obszaru, którym C wcześniej dominował. 


Oryginał tekstu w języku angielskim możesz przeczytać tutaj.

Rozpocznij dyskusję

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej