Nu, szerintem nagy vonalakban egyetértünk (valszeg kezdetektől fogva, mert az álláspontom nem változott, és valszeg a tiéd se), szóval azokra a dolgokra, amikre már reagáltam, meg elmondtam a véleményem inkább már nem reagálok.
A Rust mióta lowlevel? Meg mitől? Egy nyelv, ami a C tudásának a sokszorosát adja?
Ez ugye lehet definíciós vita... Számomra nem attól low level egy nyelv, hogy keveset tud. Hanem hogy mi a célja, mire lehet használni, milyen eszközök vannak hozzá. Szerintem a Rust simán teljesíti azokat a követelményeket, hogy low levelnek lehessen hívni. Gépi kódra fordul, simán lehet kb. sejteni, hogy milyen Rust kódból kb. milyen jellegű gépi kód lesz (nyilván nem mindenre igaz ez, de nagy vonalakban), stb. Kernelben, embeddedre, stb. lehet használni komolyabb overhead nélkül.
mivel is vagyunk beljebb a C-nél, ha nem használtuk ki a Rust-ot?
Azzal, hogy alapból biztonságosabb a nyelv. Meg egy csomó dolgot könnyeben lehet benne megcsinálni, gondolom (remélem). Ennyi. Értem, hogy Rustban is el lehet cseszni a dolgokat, stb. De mégis kisebb az esély rá, mint a C-ben. C++-ban is lehet úgy programozni, hogy "köszönöm szépen, a sok absztrakcióból nem kérek", és még így is jobb, mint a C. De amúgy azért még azt is érdemes figyelembe venni, hogy a Rust még új nyelv (C, C++-hoz képest mindenképpen), szóval kell idő neki, hogy kiforrja magát.
A compiler-bug a másik
Igen, ez benne van a pakliban sajnos.
Ezt mondjuk pont C-ben is pár sorból meg lehet oldani, csak nem osztállyal. :P
És vajon mennyire lehet könnyen használni? C++-ban meg lehet oldani úgy, hogy nem is látszik belőle semmi. Nem tudok róla, C-ben is lehetséges volna ilyet csinálni. És az, hogy ezt C++-ban meg lehet valósítani "észrevétlenül" nem a károsabb fajta absztrakció, mivel csak debugban fordulna pointer checkelősre, release-ben ugyanúgy ott van a szokásos raw pointer, szóval az átláthatóságot, a designt nem érinti egyáltalán.
Pontosítsunk: a fordító nem szólt, mert amúgy szólhatna, annyi féle warningot raktak már bele, ez sem lenne lehetetlen.
Nem igazán látom, hogy bizonyos speciális eseteket kivéve mégis hogyan szólhatna a fordító. Teljesen egyértelműen jobb a Rust megközelítése, szóval erről szerintem nincs nagyon értelme vitázni. Bocs, hogy ilyet mondok, de tényleg... Ha rendes nyelvi elem van az ilyesmire, akkor az garantálja az ilyen jellegű hibának a teljes kiküszöbölését. Míg C esetben ha szerencséd van, akkor a fordító dob egy warningot az esetek egy részére. A static analyzerek se vesznek észre egy csomó ilyesmit, nemhogy a fordító.
programozó észnél van és csak indokolt esetben használ unsafe-et és azt is ésszel
Azért feltételezek bizonyos dolgokat egy programozóról. Nem kell hozzá nagy ész, hogy ne szórd tele a programodat unsafe-fel. Ha még a program 50%-a unsafe mode-ban is megy, akkor is ott a másik 50%, ami meg biztonságos. Durván számolva akkor fele akkora a hibázás lehetősége. Szerintem akik olyan programokat írnak, ahol számít a biztonság, azért vannak egy szinten. Nyilván nem mindenki, de a nagy része igen. Nem azzal kezdik a projectet, hogy az egészet körbeteszik egy nagy unsafe-fel. Bár gondolom ilyet nem is lehet csinálni :)
Tíz éves és még egy sechole sem volt benne? Akkor valószínűleg nincs is
Ezzel nem értek egyet. Simán lehet bármilyen idős kódban sechole. Igen, ha valami régi, akkor több esély volt kiderülnie, hogy sechole van benne, de messze nem garancia. Magam is talátam hibát olyan fv-ben, ami több, mint 20 éves volt (opensource cuccban, amit ezernyi helyen használnak, konkrétan az strtod() kódjában). Nem sechole volt, egy nagyon apró hiba, de akkor is hiba. Az ember azt gondolná, hogy az ilyen alap rutinok azért már tökéletesen jól működnek.
akkor azokat hogy forgatják le azokon a platformokon, ahol nincs Rust fordító
Ha van is ilyen elterjedt platform, szerintem előbb-utóbb azon is lesz Rust.