( geza42 | 2021. 03. 22., h – 11:39 )

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?

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.

És amúgy igen, a C ebben a tekintetben konkrétan szar. Emögött nem ideológia, meg C haterkedés van, hanem ez tény. 2021-ben kb. nincs semmi értelme C-t használni, ha nem muszáj. Már a Rust előtt is volt alternatíva a C++ személyében, csak ugye Linus irracionális okok miatt nem szereti. A Rust nemtom mennyire alternatíva most, de egyértelműen abba az irányba megy, hogy az legyen.

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. 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. Nem arról van szó, hogy a buffer overflow-t tilos lekezelni C-ben. Hanem arról, hogy a Rust neked alapból megfogja az ilyen hibát, így nincs mit lekezelned. C-ben meg elfelejtheted lekezelni. 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.

É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. Az más kérdés, hogy vajon ezt az erőfeszítést érdemes-e megtenni, és nem lenne-e jobb valami más produktívabb dologba fektetni inkább a munkát.