A biztonságos kódra hangsúlyt helyező, multiparadigmás Rust rendszerprogramozási nyelvet 2006-ban kezdte fejleszteni az egykori Mozilla-alkalmazott Graydon Hoare, később pedig a cég is beállt a projekt mögé 2009-ben, majd 2010-ben a Mozilla Research hivatalosan bejelentette a Rust projektet, melynek forráskódját nyilvánossá tette. A nyelv első stabil kiadása 2015-ben látott napvilágot, majd onnantól gyors terjedésnek indult: tavaly sikerült eljutni oda, hogy az Egyesült Államok Nemzetbiztonsági Ügynöksége eddig nem látott határozottsággal kezdte szorgalmazni az alacsony szintű programozásra alkalmas, biztonságot előtérbe helyező nyelvek használatát a fejlesztők számára, mint a Rust és a Swift, miközben azt sugallta, hogy a jól bevált C és C++ használata már nem kellően biztonságos.

A 13 éves Rust az évek során beérett, és egy Mozilla-kutató mellékprojektjéből robusztus ökoszisztémává fejlődött, eközben a ma is széles körben használt C elődnyelv tavaly töltötte be az 50. életévét. Mivel a Rust biztonságosabb kódot állít elő és folyamatosan gyűjti híveit, gyorsan fordulóponthoz érkezett: a SlashData adatai szerint már 2,8 millió fejlesztő ír kódot ezzel a nyelvvel. A Microsoft, a Google és az Amazon Web Services 2019 óta használja, sőt a három vállalat 2020-ban a Mozillával és a Huawei-jel közösen megalakította a nonprofit Rust Foundationt a nyelv fenntartása és bővítése céljából.

Néhány év intenzív munka után a Linux kernel tavaly tette meg az első lépéseket a Rust-támogatás bevezetése érdekében, így már bármelyik Linux-alapú rendszer elkezdhet Rust-komponenseket beépíteni. A Google is egyre több kódot ír Rustban az Android operációs rendszerhez, és az elmozdulás jótékony hatásai már kimutathatók az elmúlt három évet nézve: jelentősen csökkent a memóriabiztonsági sérülékenységek száma a platformon. A Rustot használó meghatározó szoftvercégek sorai közt ott van az Nvidia és a Microsoft is.

Introvertáltak az IT-ban: a hard skill nem elég Már nem elég zárkózott zseninek lenni, aki egyedül old meg problémákat. Az 53. kraftie adásban az introverzióról beszélgettünk.

Az első pár évben néhány régóta aktív közreműködő aggodalommal figyelte a nyelv terjedését, felhívva rá a figyelmet, hogy amint a technológiai óriások átveszik a nyelvet, egyre nagyobb befolyást is szereznek felett, viszont ennek előnye, hogy van elég pénzük arra, hogy teljes időben dolgozó mérnököket fizessenek. A Rust csapatok vezetői közül többen például az Amazon és a Microsoft alkalmazottai, mások pedig a szabadidejükben foglalkoznak a saját projektjeikkel és könyvtáraikkal.

Ez a dinamika általánosnak mondható a nyílt forráskódú projekteknél: a nagyvállalatok megengedhetik maguknak, hogy jobban kivegyék a részüket a munkából, de ezzel olyan problémák megoldása felé terelhetik a projektet, amelyek inkább az ő érdekeiket szolgálják, nem a kisebb cégekét. Az új felügyeleti struktúrával egyszerűbbé vált az önkéntesek tevékenységének támogatása és a külső partneri kapcsolatok kiépítése. Az alapítványt az első két évben Shane Miller, az AWS Rust csapatának egykori vezetője vezette, ami egyrészt több millió dollár támogatást is kínált a Rust fő funkcióin dolgozó közreműködőknek, másrészt finanszírozza a Rust kódját tároló szervereket és a 24 órás működést. A klasszikus nyílt forráskódú felállásban ezt a munkát korábban önkéntesek végezték.

A nyelv, ami már "fenn van a neten"

Az egyes nyelvek érettsége több tényező mentén vizsgálható, de összességében elmondható, hogy az 1990 előtt született nyelvek bürokratikusabb szemléletet követtek, és főleg szervezetekkel, például az  ISO-val vagy ECMA-val dolgoztak együtt, miközben a nyelvkezelési folyamatok jól dokumentáltak voltak. Az új nyelvek kevésbé támaszkodnak a formális dokumentációra, a Rust is ebben az evolúciós szellemben folytatja útját, és saját megoldással méri, hogy a nyelv vagy a fordító fejlesztése milyen mértékben törné meg a működő kódot. A Rust ökoszisztémája gyorsan növekszik, de még mindig nem olyan kiforrott vagy kiterjedt, mint a régebbi nyelveké, például a Python vagy a JavaScript, így a részfeladatokhoz könyvtárakat vagy eszközöket találni kihívást jelenthet. 

A Rust az adattudósok számára is új lehetőség, ha a decentralizált, open source ökoszisztémák tanulmányozásáról van szó: a fiatal nyelv története könnyedén nyomon követhető a neten, ezáltal tanulmányozhatóvá válik az ökoszisztéma stabilitása és kockázatai.

A Rust ugyanolyan elvek mentén működik, mint a többi nagy nyílt forráskódú ökoszisztéma: minden fejlesztő írja a saját könyvtárait, amibe importálja a különböző függvényeket, modulokat más fejlesztőktől, így nem kell nullától kezdeni a fejlesztést, már kialakultak az alapvető megoldások.

Az OSS hátulütője a nem biztonságos kódrészek jelenléte, amik így szintén importálódhatnak egyik fejlesztőtől a másik fejlesztőhöz. Fenn áll annak veszélye is, hogy esetleg egy népszerű könyvtárat csak egy fejlesztő gondoz, aki időközben nyugdíjba mehet, vagy mással kezd foglalkozni – ekkor adott könyvtár egy idő után nem használható, a program update-ek után már nem jól működnek.

„Minden szoftvert folyamatosan karban kell tartani, vagy egy idő után már nem működik megfelelően más programokkal. Ez az egyik probléma az ökoszisztémában. Az a jó Rustban, hogy átlátható a kutatók számára, ki mikor mit írt, milyen összefüggések vannak a library-k között” - fejtette ki a HWSW-nek Johannes Wachs, a Budapesti Corvinus Egyetem docense, aki adat- és hálózattudományi módszerekkel tanulmányozza a különböző társadalmi, műszaki és gazdasági hálózatokat.

Wachs és társai „Evolving collaboration, dependencies, and use in the Rust Open Source Software ecosystem” címmel tavaly publikálták a Rust ökoszisztémáról szóló tanulmányukat a Nature tudományos szaklapban. A kutatók több mint 72 ezer fejlesztő több mint ötmillió hozzájárulását vizsgálták nyolc éven keresztül, amiket a Cargo (a Rust ökoszisztéma-könyvtár-kezelő), a GitHub és a GitLab kódtároló platformokról fésültek össze. A szakértők szerint az általuk fejlesztett módszer adaptálható más ökoszisztémákból, például a Julia programozási nyelvhez kapcsolódó adatok gyűjtésére is, de nem minden ökoszisztéma kínálja ugyanazt az adatkört, mint a Rust:

mivel a Rust viszonylag fiatal a Pythonhoz, a Rubyhoz vagy a Javascripthez képes, ezért  történetének sokkal nagyobb része érhető el a GitHubon, mindemellett viszonylag kicsinek mondható a hozzá kapcsolódó ökoszisztéma.

Szemléletesebben: míg a nagyszüleinkről csak pár analóg géppel készült fényképünk van, addig a szüleinkről, testvéreinkről jóval több felvétellel rendelkezünk, a gyerekeink pedig szabályosan túldokumentáltak az okostelefonoknak köszönhetően, ehhez hasonlóan a Rust is abban az időszakban született és fejlődik, amikor például a GitHub használata már jóval elterjedtebb a fejlesztők körében.

Az adattudósok az ökoszisztéma vizsgálatához ugyanazt a módszert használják, amivel a közgazdászok a bankrendszerek stabilitását mérik – fejtette ki Wachs a HWSW-nek. Erre példaként hozza, hogy amikor egy bank tönkremegy, vagy a csőd szélére kerül, még nincs nagy vész, mert a bankok hitelezhetnek egymásnak, de így egymást is kockázatnak teszik ki, így terjedhetnek a problémák a hálózatokon belül - ugyanezen gondolkodás mentén vizsgálják a Rust rendszert, tehát a rendszerre vonatkozóan különböző stressztesztek is futtathatók. A Rust viszont épp ezért segíthet megérteni más, nagyobb decentralizált ökoszisztémák jellegzetes problémáit, függőségeit.

A Github meglehetősen megbízható, ha adatszolgáltatásról van szó, mivel az OSS kódok körülbelül 80 százaléka elérhető a platformon. A Rust vizsgálatakor nem csak a Githubot, de a Gitlabet és a központi könyvtármenedzser Cargót is lehet hasznosítani, utóbbi platformokról sikerült kinyerni az extra 10-15 százaléknyi adatot, de Wachs szerint csak a Github használatával is hasonlóan valid elemzések készíthetők. A szakértő korábban szintén a GitHubon gyűjtött adatok alapján nézte meg az orosz és fehérorosz fejlesztők vándorlását 45 ezer fejlesztői profil segítségével. 

A szofverkutatásban dolgozók a "code smells" jelenségeket is ki tudják szúrni,  tehát a kollektív szoftverfejlesztés társadalmi és együttműködési szintjén lévő nem optimális mintákat. A tanulmány másik szerzője, Tamburri szerint ilyen például a "magányos farkas" jelenség, vagyis amikor egy fejlesztő egyoldalúan és megfontolatlanul cselekszik – vagy a „szervezeti siló” – amikor a kódbázis különböző részein dolgozó fejlesztői csapatok csak egy vagy két csapattagon keresztül kommunikálnak. A kutatók ezeket a mintázatok felfedve tudják informálni a fejlesztőket, mire figyeljenek a hálózatban, és a direkt módon használt könyvtárak veszélyeire. Az egyik probléma, hogy nyílt forrás miatt nem olyan egyszerű forrást irányítani az egyik problémás könyvtárhoz, mert a területen sokan nem pénzért tartják karban adott projektet - persze vannak izgalmas módszerek, például lehet fizetni a fejlesztőknek, a Github nemrég indított a Patreonon látotthoz hasonló szponzori kezdeményezést is.

Ha magára marad a projekt

„Az egyik probléma, hogy nincs olyan elnök vagy menedzser, aki felügyeli a dolgot, közösségként kell egyeztetni és dönteni a normákról. Az OSS szoftver paradigmájával sok embert indirekt módon tudja építeni a nagy ökoszisztémákat, amiket a nagy cégek is támogatnak. A decentralizált Rustnak szintén megvannak a maga problémái” – magyarázza Wachs.

Az open source egyik hátulütőjére, tehát az emberi tényezőre példaként említi Wachs a Rustban írt Actix webes keretrendszer történetét, melynek karbantartója teljesen magára hagyta a projektet a „mérgező webes közösség” miatt. Az Actix Webet fejlesztő Nikolay Kim korábban a Microsoft vezető szoftvermérnöke volt, de maga az Actix nem volt hivatalos Microsoft-projekt. Az Actix Web az Actix-en, az Actor modellen alapuló Rust-keretrendszeren alapul, amelyet szintén Kim fejlesztett. A webes keretrendszer egyrészt azért volt fontos a Rust közösség számára, mert egy gyakori felhasználási esetet (webes alkalmazások fejlesztését) kezelt, másrészt pedig kiemelkedő teljesítménye miatt volt népszerűvé vált, bizonyos tesztekben a benchmarkokat is vezette.

A problémás könyvtárban azonban sok volt az unsafe kód, ami felháborodást váltott ki a közösségben: ugyan a framework működött, de Rust-ellenes filozófiát követett. A Rust kódja alapértelmezés szerint biztonságos, de a nyelv támogatja a nem biztonságos kódot is, ami bizonyos esetekben a teljesítményt javíthatja. A „biztonságos” kód védett a gyakori hibáktól és biztonsági résektől, amelyek például az inicializálatlan memóriára mutató változókból, vagy olyan változókból erednek, amiket a számukra lefoglalt memória felszabadítása után használnak fel, vagy olyan változókba próbálnak adatokat írni, amelyek meghaladják a lefoglalt memóriát. 

Az Actixben viszont több „nem biztonságos” kód is volt, ami élénk vitához vezetett a közösségben a javítandó részekkel kapcsolatban, Kim viszont nem volt fogékony a más fejlesztők által javasolt változtatásokra, egyes esetekben hibajelentéseket is törölt. Az erről szóló vita a Reddit Rust fórumon hevessé és személyessé vált, a kulcskérdés pedig nem annyira a valós vagy potenciális sebezhetőség volt, hanem Kim hozzáállása.

A fejlesztő ennek eredményeként 2020. januárjában közzétett egy "Actix projekt postmortem" bejegyzést saját álláspontja megvédésére, hangsúlyozva annak terhét, hogy a nagy nyílt forráskódú projektek fenntartóinak folyton durva megnyilvánulásokat kell elviselniük, és a közösségből való kiábrándulás során ment el a kedve a projekt támogatásáról, ezért teljesen felhagy a nyílt forráskóddal. Kim állítása szerint nem törölt szándékosan bejelentéseket, csak akkoriban úgy érezte, van jobb megoldása a javasoltnál de utólag belátta, hogy nem kezelte jól a helyzetet. Egy ideig azzal is fenyegetőzött, hogy privátra állítja a repókat, de végül semmilyen drasztikus lépést nem tett, inkább átadta a projektet egy másik vezetőnek.

A történet egyik tanulsága, hogy a fejlesztők nem mindig tudják kellően hatékonyan menedzselni a közösség emberi konfliktusait, és hogy egyes közreműködők és felhasználók nem a legjobb magatartást tanúsítják az online interakciók során. Emellett nem szabad megfeledkezni az önkéntesek által végzett munka mértékéről, Wachs szerint a jövőben ez szintén egy megoldásra váró probléma.