Rust przeminie, to tymczasowa moda. @daniel1302 wczoraj długoletni programista Linuksa, H. Peter Anvin, odpowiedział na ten wątek listy mailingowej jądra.
„Andrew Piński niedawno dowiedział się o tym wątku. Zdaję sobie sprawę, że ukazał się on 1 kwietnia 2018 roku i albo był to żart, albo mógł zostać za taki odebrany. Jednakże myślę, że jest w nim słuszność i zamierzam to zrobić spróbuj uzasadnić moją opinię tutaj.
Zarówno C, jak i C++ przeszły duży rozwój od 1999 roku i C++, moim osobistym zdaniem, w końcu „wyrósł” na lepsze C dla tego rodzaju programowania wbudowanego, które uosabia jądro systemu operacyjnego. Mówię to jako autor bardzo dużej liczby hacków do makr i montażu inline w jądrze.
To, co naprawdę sprawia, że to mówię, to to, że wiele rzeczy, o które ostatnio prosiliśmy o rozszerzenia specyficzne dla gcc, jest w rzeczywistości stosunkowo łatwych do zaimplementowania w standardowym C++ i w wielu przypadkach pozwala na ulepszenie infrastruktury bez globalnych zmian w kodzie (patrz poniżej .)
C++ 14 jest moim zdaniem wersją „minimalną”, która ma rozsądną obsługę metaprogramowania i ma większość bez tego piekła typów z wcześniejszych wersji (C++ 11 miał większość, ale C++ 14 wypełnia niektóre kluczowe brakujące elementy ).
Jednak moim zdaniem C++20 naprawdę zmienia zasady gry; chociaż wcześniejsze wersje mogły odtwarzać wiele hacków SFINAE, wyświetlały także całkowicie bezużyteczne barf jako komunikaty o błędach. C++20 dodaje koncepcje, które umożliwiają uzyskanie rozsądnych błędów.
„A teraz „dlaczego nie Rust”? Po pierwsze, Rust używa innej (często, moim zdaniem, nieuzasadnionej) składni i nie tylko wszyscy programiści jądra musieliby dokładnie zapoznać się z poziomem uzyskiwania tego samego rodzaju „odczuć”, tak jak w przypadku C, ale konwersja kodu C do Rusta nie jest czymś, co można wykonać fragmentarycznie, podczas gdy po niektórych porządkach istniejący kod C można skompilować jako C++.
Uważam jednak, że nie zgadzam się z niektórymi wnioskami Davida; tak naprawdę uważam, że David jest niepotrzebnie pesymistą, przynajmniej biorąc pod uwagę nowoczesny C++.
Należy pamiętać, że nikt o zdrowych zmysłach nie spodziewałby się używać wszystkich funkcji C++. Podobnie jak mamy „jądro C” (obecnie podzbiór C11 ze stosunkowo dużym zestawem dozwolonych rozszerzeń specyficznych dla kompilatora), mielibyśmy „jądro C++”, które sugerowałbym jako ściśle zdefiniowany podzbiór C++ 20 łącznie z podobnym zestawem rozszerzeń kompilatora.) Zdaję sobie sprawę, że obsługa kompilatora C++ 20 jest wciąż bardzo nowa z oczywistych powodów, więc przynajmniej część z nich dotyczy przyszłości.
https://www.phoronix.com/news/CPP-Linux-Kernel-2024-Discuss