Szerintem ebben a dologban nem gondolunk mást.
Ebben nem. Én pontosan ezt mondtam eddig is. Még mindig nem a Rust ellen ágálok, hanem a C-hating ellen. Nagyon is megvan a létjogosultsága annak a nyelvnek.
A C rossz ("szar") ebben a tekintetben pl. a Rust-tal összehasonlítva. A Rust is low-level, mégis jobban kezeli ezt a dolgot.
A Rust mióta lowlevel? Meg mitől? Egy nyelv, ami a C tudásának a sokszorosát adja?
Ha más nyelv megoldja a biztonságos memóriahasználatot, miközben a performance alig veszik el, akkor a C rosszabb ebben a tekintetben.
Ha. Ezért lesz érdemes figyelni a sebességet, ha nekiállnak kernelmodulokat írkálni. Egy triviális probléma lehet, hogy 3%-kal lassab Rust-ban, meg 6 kB-tal több, miközben sokkal gyorsabban megvolt és safe. De mi lesz egy komplex problémával, amihez a Rust magas szintű nyelvi elemeire lesz szükség? (OOP és a többiek.) Ha használod őket, akkor a performance fokozatosan a C javára tolódik el, hiszen minél több extra mechanizmus és absztrakció kerül a kódodba, az annál több rétegcsillapítást fog rárakni. Ha meg átmész unsafe módba és megírod, mint ha C-ben tennéd, akkor lehet, hogy megint csak pár százalék meg kB a C előnye, de akkor pontosan mivel is vagyunk beljebb a C-nél, ha nem használtuk ki a Rust-ot?
Bár mondjuk hasonlóan régi a lisp, ott nincsen ilyen jellegű probléma. De persze az teljesen más tészta.
Az. Lévén az egy magas szintű nyelv, tehát nem lehet összehasonlítani a C-vel, hiába idősebb vagy 10 évvel a C-nél.
C-hater vs. ideológia: leszarom, melyik tech mögött mi van. :) Pusztán tényeken alapulva mondom azt, amit mondok.
Te lehet. De sokan meg nem. Sokan csak a trendeket, meg az épp kikiáltott vezérürüt követik.
A rustot se ismerem amúgy nagyon mélyen, egyelőre még kivárok vele, hogy jobban kiforrja magát, és akkor talán komolyabban ránézek.
Ezzel én is így vagyok. Addig C meg Pascal. :P (Mondjuk ezekről utána sem fogok leszokni, max akkor már Rust kódot is fogok írni. :P )
De ettől függetlenül lehet szabályokat hozni, hogy mit lehet, és mit nem.
Lehetni lehet, csak látod, ha fel meri emelni a hangját valami baromság ellen, akkor már "továbbképzésre" küldik, mert megint nem volt elég "befogadó".
Egyszerűen ultragáz pl., hogy a kernelben egy csomó mindent soksok soros makrókkal oldanak meg, amire mondjuk a C++ rendes megoldást ad template-ek formájában.
A Linux kernelben elég sok ultragáz dolog van már így is és nem a C miatt. Azt kell itt látni, hogy a Linux régen túlnőtt azon, hogy hobbi legyen a kockáknak, ma már komoly iparág épül rá és ennek megfelelően érdekek is fűződnek a Linux erre vagy arra történő terelésének. Az intel konkrétan hátsóajtót akart építeni a Linux véletlenszámgenerátorába (RDRAND) és csak Ted Ts'o éleslátásán múlt, hogy nem sikerült, amiért az intel strómanjai meg is próbálták mindenféle rágalommal kitúrni a projektből. De nem lehet minden beszivárgást elhárítani. Csoda, hogy Linus paranoiás és nem akarja, hogy a bevett módszereken mindenféle reformerek változtassanak? Ki tudja miféle érdekek mentén akarnak reformálni.
A pointer access-ekre is lehet wrapper osztályt csinálni, amik aztán debugban tudják ellenőrizni a validságot, és nem kell napokig keresni valami memória túlírás okát.
Ezt mondjuk pont C-ben is pár sorból meg lehet oldani, csak nem osztállyal. :P
Ettől még lehet C logikával programozni C++-ban is. A C++-t bárhol lehet használni, ahol a C-t. De jó, azt elfogadom, hogyha valami fél bites mikrocontrollerre kell valamit csinálni, akkor oda jó a C is. De ugyanúgy jó a C++ is, csak max. nem használod a feature-eit. De ha meg mégis kell valami, akkor meg ott van. Szerintem tökmind, hogy melyik fordítót hívja meg az ember.
Ezt lentebb is kiveséztük: mindegy melyiket hívod meg, de ha a C++ dolgaiból semmit sem használsz, ha a C fordító is le bírná fordítani, akkor hiába fordítottad a C++ fordítóval, az C kód maradt.
Ha valamit automatizálni lehet, akkor miért ne tegyük meg? Szerintem az egyetlen ellenérv, ami elfogadható ebben az esetben az az, hogy valami más hátránya van a Rust megoldásának. Pl. performance csökkenés. És ezt el is fogadom.
Meg mernék esküdni rá, hogy ezzel nyitottam, hogy majd érdemes lesz figyelni a sebességet...
Egyébként a performance csak az egyik probléma. A compiler-bug a másik. Hogy a védelmi mechanizmus amit belefordít, hibásan működik. A fordítót is lehet javítani persze, de ha arra várni kell, akkor az baj. Főleg, ha nem javítják azonnal, csak sok verzióval később. És ilyen előfordul, ld. a Rust 1.20 előtti stack overflow == segfault problémát. A Rust 2010-ben jött ki, az 1.20 meg 2017-ben. 7 évig ez a védelmi mechanizmus bugos volt, azaz hamis biztonságérzetet adott a felhasználóknak.
Ha valami perf. szenzitív helyen a Rust odatesz felesleges ellenőrzéseket valahova, akkor oda mehet az unsafe. És akkor észnél kell lenni, hogy pontosan mi kerül az unsafe blokkba. Viszont mindenhol máshol meg nem kell emiatt aggódni.
Ez az elmélet. A gyakorlatban meg a programozó, aki az ominózus teljesítményérzékeny részt C-ben elcseszné, az el fogja cseszni Rust-ban is, unsafe módban.
Segfault: de épp magad mondod, hogyha nincs stack probing, akkor van gáz. És ha van? Szóval ez nem a nyelvnek a sajátossága, hogy esetleg a stack overflowt rosszul kezeli, hanem implementációs kérdés.
Lehet, hogy nem nyelvi sajátosság, de ez a végeredmény szempontjából irreleváns, mert a végeredmény ekvivalens.
Más esetben is lehet segfault?
Biztos. Nem másztam bele annyira.
Amúgy el bírom képzelni, hogy igen, pl. többszálú programokkal nemtom mit csinál a rust, hogyan kezeli a race conditionokat.
Lentebb (?) írta Kiskübi, hogy lekezeli, de el nem tudom képzelni, ha van egy sokszálú, több magon futó, közös bufferrel dolgozó program, ott hogy fogják a data race-t preventálni fordítóból, úgy, hogy az ne ölje le az egészet.
A C meg nem szól. Minden programozó követ el hibákat, szóval jobb, ha a fordító tud szólni róla, minthogy runtime derül ki.
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.
De amúgy jobb lenne, ha a Rustot inkább a C++-szal hasonlítanának össze. Mert ugye ott van std::optional (jé, még a neve is majdnem ugyanaz, mint Rustban!), ami ugyanúgy tud szólni.
Ebben egyetértünk. Én nem is értem, hogy miért mindig szerencsétlen C-vel mérik össze ezeket a magas szintű nyelveket. Totál másra valóak. A C egy hordozható assembly. Ez a fő ereje és létjogosultsága, hogy a CPU-k és az OS-ek 99.99999%-án (hasraütöttem én is) elérhető, ennél hordozhatóbb nyelv nincs. A DragonFlyBSD-sek öt évet vártak vele, mire lett Rust-jük, de még mindig gáz van a Rust-os UNIX API-val alatta... És ez még csak nem is valami 9 nanobites mikrokontroller, hanem egy x86-on futó UNIX.
Hasamra ütöttem. De igaziból szerintem a számoknak még ennél is jobbnak kellene lennie a Rust javára. Ha unsafe-et csak indokolt esetben használsz, akkor a leírt memóriahozzáférések 99%-a ellenőrizve lesz (hasraütés). Tehát sokkal kissebb az esélye egy buffer overwrite-on alapuló sechole-nak.
És megint oda jutottunk, hogy ugyan az az állítás, hogy ennél a nyelvnél nem kell annyira észnél lenni, mint C-nél, ugyanakkor feltételezed, hogy a programozó észnél van és csak indokolt esetben használ unsafe-et és azt is ésszel...ez a kettő így ellentmond egymásnak. És a mai programozókat ismerve sajnos nem lesznek észnél.
Igen, de nem tudhatod, hogy egy kód biztonságosan teszi a dolgát. Nyilván működik, teszi a dolgát, OK. De hogy tutira nincs benne buffer overwrite? Hát az nem biztos.
Nem biztos, de következtetni lehet. Egy éves a modul és eddig tíz sechole volt benne? Akkor majdnem biztos, hogy van még. Lehet próbálkozni a Rust-tal. Tíz éves és még egy sechole sem volt benne? Akkor valószínűleg nincs is, vagy annyira konvulens módon lehetne kicsikarni belőle, hogy sose fogják megtalálni. Ide felesleges a Rust.
Megértem, hogy nem tetszik az a jelenség, hogy sokan csak azért hype-olják a Rustot (vagy bármit), mert új, meg trendi. De azért van technikai oka is a hype-nak.
Leírtam az elején, hogy nem a Rust-tal van a bajom. Biztos van technológiai indoklás is a hype mögött, de az valószínűleg a Rust userek kisebb hányadát érdekli, a többség megint csak a trend után megy...és hogyhogy nem, a trend már megint arra megy, hogy a C-t ircsákki, de legalábbis a Linux kernelt írják újra végre valami másban, ami nem régi (== szar), hanem valami modern, trendy és haladó. Ez közönséges gyűlölködés, ami nem csak kontraproduktív, de indokolatlan is. Mint mondtam a C legfőbb létjogosultsága a hordozhatósága, hogy bárhova viszem, ha az API különbségek le vannak kezelve, akkor fordítható lesz és az egyszerűsége, hogy azt csinálja, amit mondok neki, mint egy assembler. Ezt összehasonlítani a Rust-tal...hát mondhatni felesleges.
Egyébként, ha hordozhatóság; ha Rust részek lesznek a Linux kernelben, akkor azokat hogy forgatják le azokon a platformokon, ahol nincs Rust fordító?