Hogyan kezdtem Rust-ot használni?
Először úgy 9 éve kezdtem el nézegetni, amikor bejelentették a Rust 1.0 verzióját. Akkoriban mi még elsősorban PHP-t és Go-t használtunk. Hozzájuk képest első ránézésre nagyon furcsa volt a szintaxisa. Főleg az élettartamok tűntek nehezen felfoghatónak. Abban az időben még nagyon kicsi volt a Rust ökoszisztémája is, ezért úgy döntöttem nem fordítok rá több időt.
Nagyjából 4-5 éve merült fel újra hogy talán bekerülhetne a repertoárunkba. Addigra egész jó kis ökoszisztéma alakult ki körülötte. Kezdett úgy tűnni hogy webes alkalmazások, API rétegek írására már alkalmas lehet.
Az egyik hosszabb szabadság alatt elkezdtem végigrágni magam a nyelvet bemutató online könyvön. Látszott, hogy az élettartamok fogalmával meg fogunk küzdeni, de már nem tűnt olyan ijesztőnek mint néhány évvel korábban.
Nagyjából két-három hét alatt eljutottam odáig, hogy elkezdtem tanulmányozni a webes keretrendszereket és a kapcsolódó csomagokat. Meglepően jól lehetett haladni vele. Az hamar kiderült, hogy élettartamok miatt sem kell különösebben aggódni, csak jól át kell gondolni melyik adatnak ki lesz a tulajdonosa. Persze, vannak komplikált esetek, amiket komoly fejtörő megoldani, de az esetek döntő többsége néhány hét vagy hónap gyakorlattal már könnyen kezelhető. Mi webes környezetben használjuk a Rust-ot, így szinte minden adat két nagy csoport egyikébe tartozik: vagy az alkalmazás egész élettartama alatt elérhető konfiguráció (esetleg cache) lesz vagy csak a kérés kiszolgálásának idejére élő request-specifikus adat.
Sokak szerint a nyelv szintaxisa nehézkes, amiben van egy kis igazság. Régebben én minden kódot vi-ban írtam, ha a Rust-hoz is azt használnám akkor azért fordítási időben elég sok hibát kellene kidebuggolnom. Egy jó fejlesztői környezet - mint a JetBrains RustRover vagy a Visual Studio Code - azért leegyszerűsíti a feladatot. A szigorúan típusos nyelvnek köszönhetően az autocomplete elég jól adja az ember keze alá a lehetséges megoldásokat. Ha ezt még egy GitHub Copilot-tal is megfejeljük, akkor pedig kifejezetten gyorsan lehet vele dolgozni.
A dinamikus scriptnyelvekhez képest, mint a PHP vagy Javascript, feltűnő a "tisztaság" érzése. Itt kérem szépen rend van! Lehet erre törekedni a scriptnyelveknél is, meg is lehet próbálni kikényszeríteni mindenféle kódminőség-ellenőrző eszközökkel, de őszintén szólva azokat használni a Rust-hoz képest kínszenvedés.
Azt gondolom mondani sem kell, hogy a PHP-hez vagy a JavaScript-hez képest a teljesítmény és a memóriahatékonyság teljesen más kategória. Tényleg nagyságrendi különbségek vannak.
A két nagy C leszármazott, a Java és a .NET világához képest főleg memóriahasználatban tud elképesztően hatékony lenni a Rust.
A .NET-et viszonylag keveset használtam, de a Java-val dolgoztam néhány projecten. Nekem a Java valahogy mindig is egy nagyon körülményes nyelv volt. Olyan mintha mindig bonyolult körmondatokban kellene fogalmazni. Ehhez képest a Rust egy sokkal gördülékenyebb, praktikusabb nyelv, ahol tömören ki tudom fejezni magam. Ha elindítok egy Java alapú Spring Boot alkalmazást, nagy valószínűségggel valahonnan 50-100 MB környékéről indul a memóriaigényem. Rust-ban 5-10 MB környékéről indulunk!
Mi pár évig használtunk Go-t is. Sokan azt mondják nem érdemes Go-ról Rust-ra továbblépni, mert hatékonyságban nem olyan nagy a különbség, programozni pedig lényegesebben könyebb Go-ban. Nekem viszont az az érzésem hogy a Go kód, főleg egy nagyobb projectben, nehezebben áttekinthető. A Rust kódbázisokon valahogy sokkal könnyebben kiigazodom.
A dinamikus nyelvek esetén örök problémánk volt hogy telepítésnél mindig jókora runtime környezetet kellett magunkkal cipelnünk, ráadásul ezek a runtime környezetek néha nagyon gyorsan avultak el. Ahol kicsit hosszabb a termék életciklusa, ott bizony problémát okoz folyamatosan a legfrissebb runtime környezetekre frissíteni a kódot.
A Rust esetén, ha a kód lefordult, az valószínűleg jópár évig változatlan formában működőképes lesz, nem kell a runtime környezet támogatása miatt aggódni. Az eddigi egyetlen kompatibilitási problémánk az volt, hogy a 14 éve kiadott RedHat 6.0 változatban olyan régi kernel van, amin a legfrissebb Rust-tal fordított binárisok már nem indulnak el.
Az is nagyon tetszik, hogy a több száz MB-os PHP-s, Java-s vagy node.js-es container-ekhez képest a leszállított Rust container image-ek általában néhány MB méretűek: a lefordított binárison kívül szinte semmit nem tartalmaznak. Egy ilyen container pillanatok alatt letölthető, elindítható. Egy cloud környezetben ez óriási előny.
Sokan úgy állítják be a Rust-ot mintha elsősorban a C, C++ trónkövetelője lenne. Erre természetesen érkeznek is a jogos kritikák, hogy a két nagy öregnek számos előnye van a Rust-tal szemben. A C alapvetése az, hogy a programozó tudja mit csinál. A C fordító nem fogja semmiben akadályozni a programozót, nem ellenőriz semmit, szó nélkül csinálja amit kérnek tőle, ráadásul piszok gyorsan. Akkor is ha a programozó ezzel lábon lövi magát. Természetesen a C-ben és a C++ -ban is lehet biztonságos kódot írni, de ahhoz tudni kell milyen szerkezeteket kell használni, milyen hibákat kell elkerülni. Sokan azt hiszik, tudnak biztonságos kódot írni C, C++ -ban, mégis elkövetnek hibákat. Részben miattuk találták ki a Rust-ot, amit a teljesítmény-biztonság koordinátarendszerben kicsit máshova optimalizáltak mint a C-t vagy a C++ -ot. Egy csomó hibától megvédi a programozót, de ehhez a programozónak is együtt kell működnie: el kell gondolkodnia olyan dolgokon, mint a változók élettartama. Egy jó C, C++ programozó amúgy is megteszi ezt, még ha nem is feltétlenül ilyen tudatosan. A Rust biztonságának azonban fordítási időben igen komoly ára van: a fordítás a C-hez képest kifejezetten lassú. Futásidőben sincs ugyanolyan hatékony mint a C, de ott a különbség már jóval kisebb és inkább múlik a teljesítmény a programozó tudásán mint a választott nyelven.
Amiről kevesen beszélnek: a Rust azoknak igazán nagy "varázslat" akik a magasabb szintű nyelvek felől érkeznek. Sokan vannak, akik nem szívesen fognának egy méretesebb project implementálásába C-ben vagy C++ -ban. Egyszerűen túl sok a buktató. Nekik egy script nyelv vagy a Java, C#, utóbbi időben a Go-val kiegészülve, jó opció volt korábban. Ezekben a nyelvekben viszont a teljesítmény vagy memóriaigény könnyen elszállhat. Lehet ezt is optimalizálni, de ahhoz alaposan ismerni kell a futtató környezet és a garbage collector működését. Nekik a Rust egy új lehetőséget nyit: lemehetnek az olyan alacsony szintű nyelvek teljesítményének közelébe mint a C, C++, de nem kell feladniuk a magasabb szintű nyelvek viszonylagos biztonságát. Sőt, többszálú környezetben a Rust még a Java, Go nyelveknél is biztonságosabban használható. Ennek oka egyszerű: a Java és a Go nem véd meg a null pointer exception problémájától és a szálak közötti kritikus versenyhelyzetek kialakulásától. Ha valódi multi-threaded működésre van szükséged, ahol a szálak közösen használnak adatokat, akkor a Rust sokkal biztonságosabb választás. Emiatt szerintem a Rust nagyon sok fejlesztőt fog elszívni a magasabb szintű nyelvek irányából is, nem csak a C, C++ felől.
Én arra számítok, hogy hosszabb távon a Rust népszerűsége valahova a C, C++, Java, C# és a Go környékére áll be, vagyis a top 10-en belülre. Most még az early adopter fázisban vagyunk. Sokan kísérleteznek, szépen alakulgat az ökoszisztéma, de még relatív kevesen mernek production környezetben Rust-ozni. A saját oldalaim forgalmából az látom hogy a legtöbb érdeklődés az USA-ból és Kínából érkezik. Nem véletlen: ezek azok a területek ahol egy-egy publikált webes szolgáltatás pillanatok alatt óriási forgalommal szembesülhet a mi itthoni léptékeinkhez képest. Nézzetek rá pl. a TiKV projectre, érhető kik vannak mögötte és miért ...
Ha valahol felvetem a Rust használatát, a late adopter-ek és a lemaradók részéről persze rögtön jön a szokásos mantra: óriási költségekkel jár az átképzés, minimális előnyei vannak az új nyelvek, nem lehet rá embert találni, soha nem térül meg a befektetés, stb. Ez néhány éven belül át fog fordulni, ők meg majd futhatnak a gyorsabban kapcsolók után. A Java vagy a C# is volt fiatal nyelv. Akik ma a Rust ellen ágálnak, akkoriban a Java vagy C# ellen érveltek volna. Mindig vannak akik nem szeretnének változásokat.
Természetesen ezek a változások nem fognak egyik pillanatról a másikra megtörténni. Évek, évtizedek kellenek hozzá. Többször szembesültem vele, hogy enterprise területen bizony sok helyen a mai napig olyan szoftver-örökséggel küzdenek, ami még valamikor a 90-es évek elején kezdte a karrierjét: a VAX/VMS korszakra vagy a DOS-ra gondoljatok! Az ilyen mammutoknál minden változás nagyon sok időbe telik.