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.

Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.

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.