Linus a Linux kernel jövőjéről

Beleintegrálja a systemd-be ezt is. :P

Magyarul talán még jobban is hangzik. :-))

Végülis nem csoda, ha azt nézem hogy ma már lehet C-n kívül más értelmes nyelven is operációs rendszert írni, amit gyakorlatban bizonyítottak.

Nem csak az a fontos, hogy a nyelv alkalmas-e, hanem lehet-e embert találni, aki abban programozik. A feladatra az Ada pl. alkalmas, de nem igazán népszerű. Míg van olyan metró, aminek a szoftverét Adában írták, a Siemens villamosokon tudtommal C++-ban írt kód fut. Meg eddig inkább ilyen jellegű felhasználását ismmerem, még ha van belőle AWS is (Ada Web Server).

Erre én is emlékszem, de ezt gőgből mondta, mert tudja, hogy nem tudnak neki jobbat mutatni, vagyis próbálkozhatnak vele, de ő nemet fog mondani. Több másik interjúban már leszögezte, már évekkel ezelőtt, hogy a Linux kernel mindig is C-ben lesz, ebből csak a holttestén át enged, nem képezi alku tárgyát.

Egyébként igaza van, egyetértek vele, a C-t kifejezetten erre találták ki, hogy Unix meg unix-like OS legyen benne fejlesztve, és még a magas szintű nyelvek között még ez van a legközelebb a hardverhez, egy 50 éve bizonyított konstrukció. Lehet nem szeretni a C-t, de vitatni, hogy nem ez a legalkalmasabb erre a feladatra, azt szerintem nem.

A Rust-ot meg hiába hájpolják, szerintem egy rossz vicc. Az egész egy szutyok. Nem programoztam még benne, de forgattam le pár linuxos projektet Rust-ban, egy rémálom az egész, a függőségeivel meg mindennel. Aki nem hisz nekem, nem ismeri még a nyelvet, próbáljon pár rustos projektet forráskódból kipörgetni, majd a saját bőrén fogja megtapasztalni, hogy mi a baj vele.

Írom ezt úgy, hogy a C hozzám sem áll annyira közel, a C++ nekem mindig is szimpatikusabb volt, a típusossága meg multiparadigmás lehetőségei miatt. De azt eszem ágában sem lenne indítványozni, hogy a kernel C++-ban legyen fejlesztve.

A Google azért megpróbálta: GVisor (tudom nem igazi OS, de egy user-space Linux kernel ABI implementáció Go-ban, ami viszont nagyon érdekes állat).

Rust esetén fut a unix-szerű Redox, az RTOS-szerű Tockos és sok egyéb bare metal programming projekt.
Go az nem igazán rendszerprogramozásra, inkább alkalmazás írására tűnik használhatónak.

Viszont a D nyelv nagyon a háttérben leledzik. Ez mennyire alkalmas rendszerprogramozásra, bare metal programmingra?
https://en.wikipedia.org/wiki/System_programming_language#Major_languag…

A fordító félrefordítása ahogy írod, kicsi de valós kockázat, tehát érdemes odafigyelni. Ellenben ma sokkal nagyobb kockázat az általunk írt kódban elkövetett, például memória allokáció ill. felszabadítás körül elkövetett hiba.
Nézd meg a C és Rust példákat. Valós, elkövethető és el is követett hibák: https://web.stanford.edu/class/cs110l/slides/lecture-02.pdf
Microsoftnál volt egy ilyen projekt egy biztonságosabb C létrehozására: https://www.microsoft.com/en-us/research/project/checked-c/ ... végül kiütötte a Rust.

C elvan piszkálás nélkül, de számtalan rohadó Python2 kódot láttam már, mert az nincs el. Nyelvfüggő.

Ez kicsit attól is függ, hogy mivel kell lépést tartani.  Ha nem muszáj, én sem szeretek hirtelen váltást.  Sok szempontból nyilván alkalmas a C.  Amiben a Rust jobb:

• nincs dangling referencia
• nincs adatversenyhelyzet
• "invalid iterátor", általánosabban: átlapolt író referencia esete megtiltva
• jóval kisebb esély deadlock-ra és memóriaszivárgásra
• van rendes modulrendszer (itt panaszkodtam a C-s megoldásra)
• jobb típushelyesség, jobb const correctness
• algebrai adattípus (más nevén "tagged union", vagy kb. "variant", de jobb nyelvtannal támogatva)
• array és string slice
• lambda + closure
• aszinkron vezérlés
• implicit konverziók tiltva
• meg még sok apróság...

Semleges:

• a közvetlen hardverkezelés ugyebár semmivel nem lesz biztonságosabb, mint a C;  ezeket unsafe {} blokkba kell tenni, erre egy programnyelv nem tud garanciát vállalni.

Hátrányaként a C-hez képest talán ilyesmit mondanék:

• tényleg nehéz, főleg az elején
• beágyazott eszközökhöz, kernelhez kicsit pucolgatni kell, de meg lehet csinálni
• egyik szabályát kerülgetve (amelyikkel pl. az invalid referenciákat is tiltja) komolyabb kognitív, és minimális futásidejű terhelésre lehet számítani.  Az utóbbi mérési hiba alatt van, illetve unsafe-fel még az is elkerülhető, ha úgy tetszik.  Az előbbi viszont nem egyszerű. :)
• Ha valahol túl sok unsafe kódrészlet kell, az kissé zavaró is lehet.  Valaki azt írta, ő egy kernel hardverközeli részeit inkább Zig-ben írná, a többit Rust-ban.
• Lassú fordító.

Ha C++-hoz is viszonyítjuk:

• az OOP szintaxisát újra kell tanulni, és kicsit a szemantikát is.

Valami ehhez hasonló listát mérlegelnék.  Azért az elmúlt 50 évben történtek fejlődések.  Ha úgy gondolod, hogy megéri, akkor "go" (de nem arra a go-ra gondolok. :) )