Ha Rustban lehet ugyanolyan jellegű kódot írni, mint C-ben, és plusz még megfogja a memóriakezeléssel kapcsolatos hibák nagy részét (és más jellegű hibákat is), akkor mégis mi a gond?
Az erőltetés és a bagatellizálás; a nyelv nem old meg mindent helyettünk.
Szerintem teljesen egyértelmű, hogy emiatt automatikusan jobb lesz a kódminőség. Nem garantálja a kódminőséget, de valamivel jobb lesz.
Mitől lenne? Ha a programozó trehány, azon a nyelv nem segít. Ezt látjuk a PHP-nál, a JS-nél, a Pythonnál és a Java-nál is... Egyikben sem kell a manuális memóriakezeléssel foglalkozni, aztán mégis mennyire gány kódok születnek ezekben. (Java-ban konkrétan olyan leakelős kódokat szoktak produkálni, hogy elfolynak a GB-ok, holott az is manage-elt.)
És amúgy igen, a C ebben a tekintetben konkrétan szar.
Nem, a C az nem szar, hanem egyszerű, mint egy faék és megengedő. Pont amilyennek egy lowlevel nyelvnek lennie kell.
Emögött nem ideológia, meg C haterkedés van, hanem ez tény.
Ez minden, csak nem tény. Hogy nálad nem ideológia van mögötte, az egy dolog, de a legtöbb embernél azt látom, hogy a C-t azért utálja, mert nem a haladó informatikai eszmék része, azaz nem divatos, meg nem áll mögötte valamelyik bálványozott techcég, mint a Rust mögött a Mozilla, vagy a C# mögött a microsoft...
2021-ben kb. nincs semmi értelme C-t használni, ha nem muszáj.
Muszáj...semmit sem muszáj, de értelme miért ne lenne? Mibe írja meg az ember pl. egy mikrokontroller vezérlését, ahol csak memóriacímeket kell szinte piszkálni, a C++ feature-jei közül semmit sem használna? Hiába fordítod a C++ fordítóval, valójában C kódot írtál, mert a supersetből semmit nem használtál.
Már a Rust előtt is volt alternatíva a C++ személyében, csak ugye Linus irracionális okok miatt nem szereti.
Nem biztos, hogy annyira irracionális okok miatt. Nem biztos, hogy a nyelvet nem szereti, csak lehet, hogy látta mire képesek a C nyelvvel azok, akik nem tudják használni és nem szeretné, ha a kernelben felszaporodna az olyan OOP kódok mennyisége, amit olyan programozók írtak, akik az OOP-pal sem tudnak bánni, mert az még rosszabb lenne. Az OOP-ot is varázslatként kezelték sokáig, hogy az majd mindent megold, aztán az esetek többségében csak több problémát generált, mint amit megoldott...de ez sem az OOP hibája, hanem azoké, akik úgy használták, hogy nem tudták használni. És ez vonatkozik a C-re is.
Az pedig, hogy van a Rustban unsafe, nem érv. Nem teszed a teljes kódodat unsafe-be, hanem csak azt a részt, amit muszáj.
Ez a kettős mérce. A nyelv lehetővé teszi, tehát ugyanúgy meg lehet benne csinálni ezeket a memóriakezelési hibákat (főleg mivel pont az a rész lesz unsafe-be rakva, amit muszáj, mert az nyúlkál kétes helyekre), hovatovább, pl. stack overflow esetén továbbra is segfaultot dob a nyelv, ha nincs stack probing és ehhez nem kell unsafe. Persze a C kódot meg direkt úgy írjuk meg, hogy még a hibakezelést is kidobjuk belőle és akkor szar a C.
A kód maradék részén pedig fordítási időben ki fognak jönni olyan hibák, amik C-ben runtime jönnek ki, általában random hibák és sechole-ok formájában. Teljesen egyértelmű érv a Rust mellett.
Ez konkrétan akár bármelyik managelt nyelv mellett lehetne érv, de ha pancser írja a kódot, az minden nyelvben szar kódot fog írni.
Nem arról van szó, hogy a buffer overflow-t tilos lekezelni C-ben.
Nem tilos, csak épp le van hülyézve érte az ember, amikor meg példakódot kell írni, hogy miért szar a C, akkor abból meg direkt ki van hagyva, mert fő az egyenlő bánásmód. No comment.
Hanem arról, hogy a Rust neked alapból megfogja az ilyen hibát, így nincs mit lekezelned.
Nem, nem fogja meg mindet. Egy részét fogja meg. Mondtam példát rá, csak az valahogy elsikkadt, de nem baj, megint leírtam.
C-ben meg elfelejtheted lekezelni.
El. És ha én elfelejtem lekezelni, az a nyelv hibája és nem az enyém? Ha annyi eszem van, hogy a ráspolyt a forró tűzhely mellé teszem le és amikor megint felveszem, megéget, akkor az a ráspoly hibája, mert fémből van? A programozó hibája nem a nyelv hibája.
A compiler lehet nem fogja meg az összes ilyen hibát, de ha már megfogja a 90%-t, akkor van értelme, nem? Ha 10x kevesebb buffer overflow-val kapcsolatos sechole lesz, akkor az egy jó dolog.
Azt senki nem mondta, hogy nincs értelme, vagy nem jó dolog, hogy van. De nem véd meg mindentől. Ezeket a számokat sem tudom, hogy mire alapozod.
És amúgy lenne értelme újraírni a kernel bizonyos részeit (vagy akár az egészet) Rustban. Szerintem kiderülhetnek az átírás közben meglévő hibák, sechole-ok.
Csak akkor, ha tényleg nyerünk vele valamit. Ha egy harminc ismert sechole-lal büszkélkedhető C kódot újraírtak Rust-ban és redukálták a sechole-ok számát háromra, a teljesítményveszteség meg 5% volt, a plusz memóriaigény meg 32 kB, akkor nyertünk vele és megérte. De ha a kód tökéletesen tette a dolgát, akkor teljesen értelmetlen volt átírni, csak azért, hogy Rust-ban legyen. Erről beszéltem: ez az ideológia.