> Igen. Kérdés, hogy ha elfelejted, a fordító szól-e.
Annak a nyelvhez nincs köze, az a fordító függvénye.
> De legyen az a szabály, hogy „alkalmazásba nem írunk unsafe-et”.
Igen, így kezdődik az ideologizálás. Ennyi erővel C-ben is lehet "szabályokat" hozni.
> Megintcsak az a helyzet, hogy a Rust elvárja, hogy a szálak közt megosztott adat vagy csak olvasható legyen, vagy atomi típus, vagy lock mögé kerüljön.
Pointer Rustban is van. Mint fentebb kiderült, unsafe mód is van. Innentől kezdve a fordítónak már komoly heurisztikát kéne végeznie fordításkor, hogy rájöjjön, hogy egy elméletileg csak olvasható cross-thread adat címét én bedobtam egy pointerbe és mivel a processz által allokált területén van, így memory-access szinten férek hozzá, megkerülvén a runtime védelmi mechanizmusait. Nyilván ez nem a Rust hibája, hanem a hülye programozóé, aki ilyet csinál, de 100%-ig hülyebiztos rendszer nincs. És itt megint előállt, hogy vagy engedem, vagy tiltom, a kettő keveréke nem létezik, az az engedem, de szívatom a felhasználót kategória.
> C-ben csak a lehetőségünk van meg, hogy lock-oljunk. Ha elfelejtjük, az undefined behaviour.
Ez nem mond ellent annak, amit mondtam. A C a lehetőségek nyelve. Az öntökönlövésre is, de másra is.
> Gyakran átesik a teszteken, piszok nehezen reprodukálható, következményét tekintve pedig egy segfault a szerencsésebb esetek közé tartozik, mert nyugodtan össze is firkálhatja a memóriát, és adatvesztést okozhat.
Ez így van, de unsafe és/vagy rossz kódot bármilyen nyelven lehet írni.
> A felszabadítást igen, a referenciák (ha vannak raw referenciák) lifetime-ellenőrzését nemigen. Szintén undefined behaviour-t szűrünk ki ezzel, ráadásul olyat, ami a jelenlegi bugok elég nagy részét képezik.
Ez implementáció kérdése. Le lehet implementálni C-ben és egyéb nyelvekben is. A Rust akkor ezt itt default runtime szinten támogatja, ennyi a különbség.