Bevezető a Rust borrow checker működésébe

Mostanában sokat foglalkoztam a Rust-tal és magyarul eddig még nem nagyon találtam ezzel kapcsolatban tartalmakat. Elkezdtem írni egy kis cikksorozatot ami a borrow checker működéséről szól, talán ez a nyelv legnehezebben érthető része.

Itt találjátok, remélem hasznos lesz valakinek: https://apatisandor.hu/hu/tags/borrow-checker/

Szélesebb körnek szól, ezért angolul kezdtem el egy másik szálat, ami azt mutatja meg hogyan lehet egy REST API-t implementálni Rust-ban, ezzel kicsit lassabban haladok: https://apatisandor.hu/tags/dog-shelter/

Kezdő vagyok még publikálásban, remélhetőleg érthető a tartalom ebben a formában. Ha valahol egyértelmű hibát találtok benne, jelezzétek kommentben és javítom.

( ibenny v | 2023. 12. 30., szo – 16:34 )

Jó anyag lett, köszi, elolvastam a borrow checker-es bejegyzéseket! A publikálási forma is tetszik, jó kis blog.

( Nyosigomboc v | 2023. 12. 30., szo – 17:00 )

Nem tetszik a nyelv par resze, de tervbe van veve, hogy megtanulom ezt is. Tudsz ajanlani olyan tutorialt, ami Rustban kezdoknek valo, de programozasban mar tapasztaltabbaknak? (jopar masik nyelvet ismerek, de ezt pont nem)

A strange game. The only winning move is not to play. How about a nice game of chess?

Őszintén szólva nem találtam ilyet. Én egyszerűen nekiálltam a Rust Book-nak és kb. 1-2 hét alatt végigrágtam magam rajta. Ha ismersz más nyelveket akkor vannak gyorsan lapozós részek, sokminden ismerős lesz a korábbi nyelvekből. A struct-ok és trait-ek szisztémája eléggé eltér a máshol megszokott class-interface szemantikától, arra érdemes több figyelmet fordítani. A másik jelentős eltérés más nyelvektől az enum-okkal megoldott hibakezelés.

( trey | 2023. 12. 30., szo – 17:09 )

Szélesebb körnek szól,

Akkor főoldal!

trey @ gépház

( crypton | 2023. 12. 31., v – 09:47 )

Végigolvastam, nagyon jó, a blog is, illetve a témák is. Gratulálok! Remélem lesz még folytatás.

( hory v | 2024. 01. 01., h – 12:58 )

Szerkesztve: 2024. 01. 01., h – 12:59

Nekem igazabol azert volt erdekes, mert uj. A rust borzalmas gyorsan valtozik, par eves borrow checker doksik mar teljesen elavult (ugye azota bejott az async fn, az -> impl trait, meg meg sok-sok egyeb). Jo volt latni, hogy nez ki a friss, uj rust, igazabol egesz pofas lett, de meg mindig sokat, sokat kell fejlodnie, mielott igazan mainstream lesz.

Egyszeru, tomor, konnyen olvashato doksit irtal, kivalo syntax highlight-errel, jol emesztheto peldakkal, kudos!

( turul16 v | 2024. 01. 01., h – 17:52 )

Like

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( arpi_esp v | 2024. 01. 01., h – 18:17 )

Szerkesztve: 2024. 01. 01., h – 18:19

koszi. az elso reszt elolvastam, erdekes volt.

sajnos en meg mindig nem tudok elkepzelni olyan feladatot/problemat, aminek pont rust-ban allnek neki. a szintaktikaja borzalmas, a kotottsegei miatt olyan mintha hatrakotott kezzel kene c-ben fejleszteni, a nem valtoztathato valtozok es hasonlo baromsagok minatt inkabb mazoistaknak valo szerintem :)

pedig nem lenne rossz egy nyelv a C es a Python kozott, ami a 2 nyelv elonyeit egyesiti, de nekem a Rust olyan mintha a 2 nyelv hatranyait egyesitene csak :)

Ez szerintem nagyon attól függ ki milyen irányból érkezik a Rust-hoz. Aki az assembly és a C irányából érkezik, rutinos azok használatában, annak valószínűleg tényleg elviselhetetlenül nehézkesnek tűnhet a Rust a sok kötöttségével. Ugyanakkor aki a scriptnyelvek (PHP, Python, Javascript, stb.) vagy a garbage collectoros statikusan típusos nyelvek (Java, C#, Go) irányából érkezik, az kap egy igen hatékony, de biztonságos eszközt, amivel nem fogja rögtön első próbálkozásra lábon lőni magát. Programoztam C-ben (hozzáteszem nem túl sokat), de amikor azzal dolgoztam mindig ott volt a fejemben hogy minden részletre figyelnem kell, mert egyetlen apró hiba is nehezen debuggolható segfault-hoz tud vezetni. A Rust-tal sokkal bátrabban dolgozhatok, mert a fordító fogja a kezem, nem enged hülyeséget csinálni. A dolog egy másik aspektusa az emberi tényező: mindenki hibázik, a legjobb C fejlesztők is. A Rust szabályrendszere pedig segít fordítási időben megfogni nagyon sok hibát. Ha lazítani kell a merev szabályokon, akkor még mindig ott van az unsafe kód lehetősége, a Rust alacsonyszintű komponensei természetesen rendszeresen használják is ezt az opciót. Ott akár még inline assembly-t is lehet használni. A lényeg hogy ezek a kockázatos kódrészletek kis területre koncentrálódnak és remélhetőleg csak azok kezdenek el ilyesmin dolgozni akik rendelkeznek is a megfelelő tapasztalattal.

> Aki az assembly és a C irányából érkezik

hat en onnan, kb 35 eve assemblyzek, bar az utobbi 20 evben mar inkabb C a portolhatosag miatt (na meg egyszerubb az eroforras/regiszter allokaciokat a compilerre bizni), de C kodolaskor is fejben azt "latom" mire fog lefordulni, hogy tudja a CPU ezt megoldani, kb hany utasitas/orajel lesz stb...   valoban nagyon esznel kell lenni, de aki gepikodban gondolkozik annal ez alap ugyis

amikor meg nem szamit a sebesseg, de gyorsan kell osszedobni valamit (foleg ha szoveg parsolas/feldolgozas/scripteles) akkor arra meg ott a python.  szivesen irnek mindent C-ben, de a C-s string manipulacio ugye tudjuk milyen (leginkabb semmilyen). C++ lehetne meg opcio, de valahogy azzal se vagyok kibekulve :)

> A Rust-tal sokkal bátrabban dolgozhatok, mert a fordító fogja a kezem, nem enged hülyeséget csinálni.

volt mar egy ilyen nyelv, az ADA, amit pont erre talaltak ki, de nem terjedt el (talan raketavezreleshez meg ilyesmihez hasznaltak anno)

volt mar egy ilyen nyelv, az ADA, amit pont erre talaltak ki, de nem terjedt el (talan raketavezreleshez meg ilyesmihez hasznaltak anno)

Rust esetén ez a veszély úgy tűnik, hogy nem fenyeget, mert már a Linux/Windows kernelek, az alacsony szintű programok, a magas szintű programok, a web alkalmazások, de még a frontend (web assembly) programozásban is eléggé elterjedt és folyamatosan nő a népszerűsége.

Hat amig k8s go addig nem hinnem hogy eltunne.
Python -rol at lehet szokatni ra az embereket, es alapvetoen gyorsabb .
De mark-sweep szemet gyujtos, python hoz kepest legalabb megy tobb magon, nem mindig a legjobb eredmeny hozza az M:N threading.

(Note: cpython hoz is van parallel patch, de cserebe single core megy visza 10% -ot, ill mark-sweep).

zig a rust kihivo:
https://en.wikipedia.org/wiki/Zig_(programming_language)
("See also" resznel meg van egy par)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Én a zig-et a C és a Rust közé tenném. Alacsonyabb szintű mint a Rust, jobb teljesítményt és jobb C kompatibilitást céloz meg, de a biztonsági garanciái nincsenek olyan erősek mint a Rust safe módjának garanciái. A zig még nagyon fiatal, a Rust úgy 8-10 évvel idősebb. A bun.sh mindenesetre most ráirányította a figyelmet.

Swift-et próbáltad már? kb pont azokat tudja mint a Rust (igazából nem csoda, mert mind2 az LLVM IR-jére épít, csak ugye itt a nyelvet is az írta, aki az LLVM-et, nem csak úgy össze lett tákolva), csak nem kap az ember hányingert, amikor ránéz a kódra +alapból van benne C interop.

nem csak úgy össze lett tákolva

Ehhez képest a Rust esetén még nem volt breaking changes a 8 év alatt, a Swift esetén már több is, átlag 2 évente. Rengeteg olyan megoldás van benne, ami éppen azt jelzi, hogy mennyire átgondolt volt a fejlesztése, pl. Exception helyett érték alapú hibakezelés, Type class, memóriakezelés, ...

csak nem kap az ember hányingert, amikor ránéz a kódra

In the 2023 Stack Overflow Developer Survey, 13% of respondents had recently done extensive development in Rust.[192] The survey also named Rust the "most loved programming language" every year from 2016 to 2023 (inclusive), based on the number of developers interested in continuing to work in the same language.[193][note 8]

Azért van aki nem kap hányingert tőle ;-)

( fairlane | 2024. 01. 02., k – 01:53 )

Köszi szépen, sokat segített!
Jöhet a folytatás. :)

...úgyis jönnek...

( khiraly | 2024. 01. 02., k – 02:49 )

Lazan kapcsolodva:

Par hete tetszett egy javascript megvalositas.

A projekt utolso kommitja 2 eve tortent. Az akkori verzioju node.js+npm-mel nem sikerult telepiteni.A legujabb node.js+npm is behasalt a dependency hell-be.

Vegul a package.lock alapjan egy regebbi node.js be csak sikerult elinditani (npm continous integration kapcsoloja).

 

((az ironia az egészben, hogy egy olyan reszt szedtem ki, amiben az volt a plane, hogy javascript nelkuli megvalositas (histogram, point cloud ), tisztan css+html template. Csak bele volt teve egy javascript frameworkbe a generalas:))

 

A minap egy komolyabb cpp-s projektet inditottam (komolyabb az 10+ cpp fajl:), ahol 7 eve volt az utolso kommit es pocc-roff.

pythonban is rendszeresen el tudok inditani mindenfele buveszkedes nelkul 4-5-6 eves projekteket.

Innen nezve a cradle/crates.io a rustban jobban hasonlit a javascriptes npm-re, mint a pythonos "battery included" vonalra.

 

Errol van valakinek komolyabb tapasztalata?

Elo lehet venni egy 4-5 eves projektet es folytatni a munkat, relative egyszeruen?

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Még nincs 4-5 éves a legrégebbi kódunk sem, de az látszik hogy nagyon gyorsan fejlődnek a crate-ek. Eddig egy hasonló jellegű problémába futottunk bele: a Rust 1.64-es verziójával megszűnt a régebbi linux kernelek támogatása, beleértve az RHEL 6-ot is. Nekünk viszont van olyan target-ünk ahol még pár hónapig biztos RHEL 6-on kell futnia egy alkalmazásnak, így le kellett horgonyoznunk az 1.63 verziónál. A problémát az okozta, hogy az aktuális crate verziók már nagyon sok helyen függnek az 1.64-es vagy újabb Rust verziótól. A megoldást egyelőre az jelenti, hogy a crates.io verziókezelt, ezért letöltöttünk egy snapshot-ot ami az 1.64-es Rust verzió kiadása előtt készült és abból dolgozunk. Ha mondjuk kijönne egy kritikus biztonsági javítás valamelyik felhasznált crate-re, akkor kicsit bűvészkedni kellene hogy beépítsük, de meg tudnánk oldani.

( Barnabas | 2024. 01. 02., k – 19:47 )

Woho, ezt megérte címlapra dobni! Ritkán van kontent, de ha van, akkor az hiánypótló - főleg magyar nyelven.