"Rust a Linux kernelben"

Nem-nem, unsafe módban crashelő kódot én adtam, te viszont utána megmutattad, hogy nem kell, hogy a crash-t okozó sor maga is unsafe módban legyen, elég, ha az általa használt adat unsafe forrásból érkezett.

Egyúttal itt jegyzem meg, hogy a forráskódból az unsafe blokk warning-olható vagy tiltható a forráskód elejére tett opcióval. Így meg sem kell nézni a hátralevő részét, hogy van-e benne.

#![warn(unsafe_code)]
//#![forbid(unsafe_code)]

fn main() {
    let x = [10, 20, 30];
    println!("Csak teszt: {}", x[0]);
    unsafe {
        println!("Csak unsafe teszt: {}", x.get_unchecked(0));
    }
}

$ rustc pelda.rs

Így van: igaz ez minden szakmára.
Ahogy az is, hogy sok helyen megpróbálnak trükközni és költséget externalizálni.
Ilyen, amikor egy vendéglő nem fizet a szemétszállításért, hanem műszak végén a dolgozóknak hazafelé kell teríteni a zsákokat lakótelepi kukákba. Vagy amikor nem szakácsok főznek, hanem tinilányok vagy öreg nénik. (True story mindegyik.)

A programozás terén is megvannak ezek megfelelői.

érvelésed alapján mindent assemblyben kellene írni

Hát én rohadtul nem ezt mondtam. Szó szerint leírtam, hogy senki nem mondta, hogy mindent is a kézireszelővel... Így nincs értelme vitázni, ha nem az ellen érvelsz, amit mondtam.

A rust látott néhány jellemző problémát a szerszámmal, és megpróbált ezekre jobban odafigyelni, ennyi ez, nem több, nem kevesebb.

Ezzel nincs is semmi baj, sőt ez egy baromi jó dolog. Az már nem annyira, hogy erre építve vallási hadjáratot indítanak a többi koncepció ellen.

Az ideológiai "kiirtani típusú" félelmeiddel nem nagyon tudok mit kezdeni, nem szeretnék érdemben beleszólni. (Csak nagyon zárójelben jegyzem meg, hogy dehogynem akarták, géprombolás volt a jelenség neve, még a történelem könyvekben is benne van ;)

A hasonlatod két okból is fals: egyrészt ott egy munkafolymat lett gépiesítve, nem pedig egy szerszám erőszakosan lecserélve egy másikra, másrészt meg mert itt elég nagy átfedés van a reszelősök és a CNC-sek között; ott meg a munkások és a gépek között nem is lehetett átfedés.

Olvasd el újra az eredeti mondatot, aminek csak a második felét idézted be. A bináris létre sem jön, mert a fordító elszáll hibával, egy nem létező binárist pedig nem lehet futtatni, így nem is okozhat hibát.

Jogos, elsiklottam felette (mentem volna már enni). Nem létező binárisban valóban nem lesz hiba. Viszont akkor mondom, hogy van egy harmadik lehetőség is, amit kihagytál: nem csak le nem forduló, vagy nem megfelelően lefordított kód van, hanem megfelelően lefordított, de a fordító bugjából eredően mégis hibásan működő kód is. Ez volt az, amikor a stack probe-ing hiányában egy kellő mélységű rekurzió eltrashelte az egész vermet. A megírt és a lefordított kód is jó volt (lévén amíg nem ért el egy bizonyos szintű rekurziót, tökéletesen működött), csak éppen az maradt ki belőle, amivel a Rust állítólag kitűnik a többi nyelv közül: az idevágó validáció.

A lényeg a mennyiségen van. A világ összes C vagy Rust kódja vajon hány nagyságrenddel több, mint egy Rust vagy C fordító kódja?

És a világon vajon hány nagyságrenddel több C-t beszélő programozó van, mint Rust-ot? És a C-s programokból vajon hány nagyságrenddel van több a több nagyságrenddel kisebb komplexitásúakból? A mennyiséget sokfelől lehet nézni.

Nem az automatizmus validálja önmaga működését, hanem annak a használata. Pl. ha van egy unit tesztem ami 100x sikeresen lefutott de 101x alkalommal hibára futott, akkor vagy a kódban történt olyan változtatás, vagy a tesztben van olyan hiba, ami miatt a teszt elhasalt. De ha kiderül, hogy a tesztben van a hiba, akkor nyilván a tesztet kell javítani, nem a kódot. Ezáltal a teszt még jobb lesz, még megbízhatóbban talál meg hibákat a tesztelt kódban.

De itt most magáról a fordító védelmi automatizmusáról volt szó, nem pedig külső automatizmusokról. Az nem validálhatja önmagát. Kívülről persze, hogy lehet validálni, hogy a fordító validátora jól működik-e, de ennyi erővel ilyet a C kódokra is lehet írni.

Nem is kell megvédenie mindentől. Az is előrelépés, ha csak a gyakori hibáktól véd meg.

Kiket? A hülyéket? Esélytelen. Azok baromságot fognak csinálni. Olyat, amire a Rust fordítók írói legbrutálisabb rémálmaikban sem gondoltak. A többit? Azok Rust nélkül sem csinálnak olyan sok hibát. Lehet, hogy a Rust-tal még annyit se csinálnának, de cserébe jól lelassítja őket, hogy kerülgethetik a nyelv által támasztott akadályokat. (Nem, nem arra gondoltam, hogy unsafe-fel bypass-olják, hanem, hogy rendesen megírják.)

Ha a markolat csúszós anyagból készült, vagy nem megfelelő a textúrája, az bizony az eszköz, illetve a gyártó hibája. A fej rögzítése szintén nem a felhasználó dolga, hanem a gyártóé.

Tehát nem magának az eszköznek - a kalapácsnak: en-generique a kalapács koncepciójának - a hibája, mert a kalapács koncepciója az, hogy oda tudjál vele baszni egy jó erőset valahova és a markolat anyaga vagy kialakítása, meg a fej rögzítése nem része a koncepciónak, ahogy az sem, hogy hova baszol oda vele. Ha annak a kalapácsnak tényleg szar a markolata, vagy nincs rögzítve a feje, akkor fogsz egy másik gyártó által készített kalapácsot és le van tudva. Ha a C compiler, amit használsz szar, fogsz egy másikat. Rust-ból viszont csak egy van.

Ha egy hobbi pilóta kisgépe lezuhan, az legfeljebb neki és a családjának, barátainak fáj. Ha egy utasszállító lezuhan, az még érint pár száz embert, akik azért fizettek, hogy biztonságosan eljussanak A-ból B-be.

Hány utasszállító gép van a világon és hány sárkányrepülő és egyéb kis csipszar, vagy bármilyen automatikamentes - akár négy légcsavaros teherszállító - gép és arányaiban miből potyog le több? Van erre valami statisztika?

a légitársaságok érdeke, hogy a légiközlekedést minél biztonságosabbá tegyék

Akkor minek csinálnak ilyeneket? A pilótákat nem rátermettség alapján kéne kiválogatni és kiképezni?

Ugyanígy ha egy hobbiprogramozó kódjában van egy memóriakorrupciós hiba, az kis számú felhasználót fog érinteni és kis kárt fog okozni. Viszont ha a Linux kernelben van memóriakorrupciós hiba, az egyrészt komoly károkat okozhat rendszerek feltörése által, másrészt magas költsége lehet a hiba elhárításának. Ezért a Linux kernelre építő cégek (kb. a világ összes cége) érdeke, hogy a Linux kernelben kevés legyen a memóriakorrupciós hiba.

És ennek az a feloldása, hogy bármi áron, de átírjuk egy olyan nyelvre a Linux kernelt, meg minden egyéb kulcsszoftvert, amiben ugyanúgy lehet memóriakorrupciós hibát csinálni, ha nagyon akarod, viszont legalább egy fúziós erőmű kell ahhoz, hogy lefordítsd (a Rust saját magát 32-bites gépeken le sem tudja fordítani, mert nem tudnak annyi memóriát kicímezni) és az eddig támogatott platformok száma a töredékére zuhan vissza, de legalább a nagy cégek megint jól jártak, mert megsemmisítették a mindenki által beszélt C-t és helyette egy olyan nyelvben van már minden, amit csak az ő programozóik ismernek?

Erre most is van példa, ellenőrzött légtérbe nem repülhet be akárki. De ez nem zárja ki, hogy mások is repülhessenek.

Nem arról volt szó, hogy nem repülhet be akárki egy "zárt" légtérbe, hanem, hogy minden automatikamentes gépet letiltunk, mert "nem biztonságosak".

Ugyanígy ha a Linux kernelben lesz lehetőség Rustban programozni, az nem fogja kizárni, hogy továbbra is C-ben programozz.

Ha elkezdik átírni rá? Ez már a másik topicban is volt: ha új modulokat írnak Rust-ban, az nem gáz, maximum az nem lesz mindenütt elérhető, de ha a régi kódokat kezdik el átírni, azt elveszik mindenkitől, aki nem beszél Rust-ban és minden platformtól, ahova nincs Rust fordító.