Kérdezz meg két tapasztalt Rust-fejlesztőt, megérte-e megtanulni a Rustot, és teljesen ellentétes válaszokat kaphatsz. Az egyik azt mondhatja, hogy semmit sem adott a karrierjéhez; a másik a legjobb technikai döntései egyikének nevezheti. Mindkettőjüknek igaza lehet.
Ebben az ellentmondásban rejlik valójában a „megéri-e megtanulni a Rustot” kérdés, és ezért nem ér semmit egy általános igen. A Rust egy fordított nyelv, amelynek biztonságos részhalmaza fordítási időben kényszeríti ki a memóriabiztonsági szabályokat, anélkül hogy futásidőben szemétgyűjtőre lenne szükség.
Úgyhogy vállalok egy választ, megnevezem a feltételt, amelyen múlik, és megmutatom, mibe kerül ez a feltétel.
A rövid verzió
A Rustot akkor érdemes megtanulni, ha valami hosszú életűt építesz, ahol megéri fizetni azért, hogy a fordító elkapja a hibák egy egész osztályát. Rossz választás, ha még ebben a hónapban ki kell adnod egy CRUD-alkalmazást, most tanulsz programozni, vagy álláshirdetéseket számolsz. 5-ből 4, levonással azért, amibe kerül, mielőtt megtérül.
- Amit megveszel: a biztonságos Rustban a tulajdonlási és kölcsönzési szabályok a use-after-free, double-free, érvénytelen hivatkozás és adatverseny típusú hibákat fordítási hibákká alakítják éles incidensek helyett. Ez az egész ajánlat lényege, és jó ajánlat.
- Amivel fizetsz: a fordító arra kényszerít, hogy leírd azokat a memóriadöntéseket, amelyeket a jelenlegi nyelved csendben meghoz, és ez eleinte olyan érzés, mintha az eszköz csak akadékoskodna.
- A tartósság kérdése eldőlt. A kernelkarbantartók a 2025 decemberi Maintainers Summiton lezárták a Rust-kísérletet, és a Linux 7.0-ban lekerült a „kísérleti” címke.
- A divat kérdése nem dőlt el, és az egy másik kérdés. A Rust a #10 helyen áll a TIOBE 2026. szeptemberi indexében, egy évvel korábban még a #18 helyen volt.
- A teszt Rust-szolgáltatásomnak sokkal több memória kellett a fordításhoz, mint a futáshoz: fordítás közben 1 GB körül tetőzött, futás közben pedig üresjáratban nagyjából 3,5 MB-ot használt.
- Neked való, ha már szállítasz szoftvert egy másik nyelven, és olyasmit építesz, ahol egy memóriahiba drága lenne, vagy rendszerszoftverek közelében dolgozol. Nem neked való, ha szorít a határidő, nulláról kezdesz, vagy azt a nyelvet keresed, amelyre a legtöbb állás van.
Hogyan készült ez az értékelés: a fordítási és futási számok itt az enyémek. Telepítettem a Rust 1.98.1-et, írtam egy kis Axum webszolgáltatást, és megmértem, mibe került a fordítás és mibe a futtatás. Mindez egy izolált konténerben futott, nem dedikált hardveren, és ez egyetlen projekt, úgyhogy a számokat adatpontként kezeld, ne törvényként. Minden más elsődleges vagy hiteles forrásból származik: a kernelpatch és az LWN beszámolója róla, a Google Android-biztonsági bejegyzései, a TIOBE saját indexe (az áprilisi kommentárral a Slashdot rögzítése alapján), a Phoronix a Linux 7.0 merge window-járól, a Linux kernel CVE-bejegyzései a Binder-sebezhetőségről, a Canonical saját közleménye és a 2025-ös Stack Overflow felmérés. A kernelpatchet elolvastam. A kernel Rust-kódját nem auditáltam. És nem írok évek óta Rustot, így ahol ez az értékelés magát a nyelvet ítéli meg, ott olyan gyakorló fejlesztőkre támaszkodik, akik igen, és meg is nevezi őket.
Mit ad neked a fordító
Adj Rustban két szálnak módosítható hivatkozást ugyanarra a vektorra, és a kód nem fordul le. Nem figyelmeztetés. Nem egy lint, amit határidő előtt elnémíthatsz. Egyszerűen nem fordul le. Ez az elutasítás az, amit a biztonságos Rustban megveszel: a use-after-free, double-free, érvénytelen hivatkozás és adatverseny típusú hibák fordítási hibákká válnak éles incidensek helyett. A Rust vészkijárata (unsafe) megkerülheti ezen garanciák egy részét, így ez nem abszolút ígéret minden Rust-kódbázisra.
A tulajdonlás azt jelenti, hogy minden értéknek pontosan egy tulajdonosa van, aki a felszabadításáért felel. A kölcsönzés azt jelenti, hogy kölcsönadhatsz hivatkozásokat, de a fordító követi az élettartamukat, és nem engedi, hogy egy hivatkozás túlélje azt, amire mutat, sem azt, hogy egy módosítható kölcsönzés bármely mással egyszerre létezzen. A biztonságos Rustban a use-after-free, double-free, érvénytelen hivatkozás és adatverseny típusú hibákat a tulajdonlási és típusrendszer még a program futása előtt elkapja.
Nincs szemétgyűjtő, és ez az üzlet másik fele. Mivel a tulajdonlás már megmondja, ki mit és mikor szabadít fel, futásidőben semminek sem kell bejárnia a heapedet. Olyan binárist szállítasz, amelyben nincs gyűjtő, és nincsenek szünetidők, amelyekhez hangolnod kellene.
Az ár ugyanott jelentkezik, ahol a garancia. Minden memóriadöntést, amelyet a jelenlegi nyelved csendben meghoz helyetted, a Rust megkér, hogy írj le: kié ez, meddig él az a hivatkozás, láthatja-e bármi más, és átlépi-e egy szál határát. A fordító nem akadékoskodik. Egyszerűen nem hajlandó találgatni.
Tehát: ez az oka annak, hogy bárki megfizeti, amit a Rust kér, és szerintem ez megállja a helyét. Ha a hibaosztály, amelyet kiküszöböl, nem olyan, ami miatt aggódsz, az értékelés további része valószínűleg nem változtat a véleményeden.
Kísérleti még a Rust, vagy már éles infrastruktúra?
2025 decemberében szűnt meg kísérleti lenni, és maguk a kernelkarbantartók zárták le. A 2025-ös Maintainers Summiton arra jutottak, hogy a Rust megállta a helyét a kernelben, technikailag és közösségileg is. Az LWN-es Jonathan Corbet 2025. december 10-én számolt be a konszenzusról: a Rust a kernelben már nem kísérleti.
A Rust 2022-ben a v6.1-gyel került be a fő Linux-ágba, kifejezetten azért, hogy lefuttassák ezt a kísérletet. A címkét eltávolító patch, amelyet Miguel Ojeda írt, három nappal a Summit után érkezett, és bekerült a Linux 7.0 merge window-jába.
„De a kísérletnek vége, azaz a Rust itt marad.”
Miguel Ojeda, „rust: conclude the Rust experiment”, LKML, 2025. december 13.
Ettől függetlenül, és korábban: az Android Binder-illesztőprogramjának a Google által Rustban újraírt változata, az az IPC-réteg, amelyen keresztül az Android folyamatai (folyamatosan) kommunikálnak, bekerült a Linux 6.18-ba, amely 2025. november 30-án jelent meg. Ezt a mérföldkövet tartsd külön a Summit konszenzusától. Ez az, ahol egy cég egy szállított terméket tett fel a kernel Rustra, nem pedig egy karbantartói csoport áldotta meg az ötletet. A kernel Rust azóta megkapta első CVE-jét: CVE-2025-68260, egy versenyhelyzet ugyanabban a Binder-illesztőprogramban, amelyet Greg Kroah-Hartman 2025. december 16-án jelentett be, a 6.18-ban került be és a 6.18.1-ben javították. Az első beszámolók az összeomlásokra összpontosítottak, de a Linux kernel CVE-csapatának későbbi pontozása 7,8-ra (magas) értékeli a CVE-2025-68260-at, és kernelmemória-sérülésen keresztüli helyi jogosultságkiterjesztési útvonalat ír le. Ugyanaz az illesztőprogram (rust_binder) azóta további CVE-ket is gyűjtött.
Az Androidnál kapnak számokat a bizonyítékok. A Google biztonsági blogja 2022 decemberében azt írta, hogy egyetlen memóriabiztonsági sebezhetőséget sem fedeztek fel az Android Rust-kódjában, miközben az AOSP-ben nagyjából 1,5 millió sor Rust volt, és ez az Android 13 összes új natív kódjának körülbelül 21%-a. Ez egy 2022-es állítás 2022-es hatókörrel. A Google későbbi bejegyzései a hosszabb trendet mutatják: a memóriabiztonsági problémák adták az Android sebezhetőségeinek 76%-át 2019-ben és 24%-át 2024-ben, a nyers szám pedig több mint 220-ról várhatóan 36-ra esett. Ezek a számok csak annak az alapnak a fényében jelentenek valamit, amelyet felváltottak, ez pedig a nagyon jó mérnökök által nagyon jó eszközökkel írt C és C++.
Két kisebb jel ugyanebbe az irányba mutat. Az Apple AGX GPU-illesztőprogram az Asahi Linuxban Rustban készült, és nem az Apple írta, hanem az Asahi Linux projekt, visszafejtéssel. A Canonical rust-coreutils frissítése szerint az Ubuntu 26.04 LTS a legtöbb segédprogramhoz a rust-coreutils 0.8.0-t szállítja. Három a GNU coreutilsnál marad (cp, mv, rm), mert 2026. április 22-én még nyolc TOCTOU-probléma volt nyitva; a Canonical a maradék segédprogramokat a 26.10-re célozza.
Ezt a szempontot értékelném a legmagasabbra, és az ok a vállalt elköteleződés jellege. A kernelkarbantartók nem vonják vissza a lezárt kísérleteket, a Google nem csinál vissza egy ekkora újraírást, és a Canonical nem tesz egy újraírt coreutilst egy LTS-be csak azért, hogy lássa, mi lesz. Bármi történik a Rust népszerűségével, valakinek évekig karban kell tartania azt a kódot.
Halott a Rust, vagy csak megtorpant?
Nem. A Rust 2026 januárjában beállította minden idők legjobb TIOBE-helyezését, a #13 helyet. Három hónappal később visszaesett a #16 helyre, és a TIOBE vezérigazgatója, Paul Jansen 2026 áprilisában, a Slashdot által akkor idézett kommentárjában azt írta, hogy a Rust népszerűségének növekedése „úgy tűnik, lelassul”, és hogy a top 10-es hely „most távolabbinak tűnik, mint korábban”.
Azt írta le, ahogy a Rust elérte minden idők legjobb helyezését a saját indexén, azt a helyet, amelyet először 2024 júliusában foglalt el, majd újra elvesztette.
A TIOBE 2026. szeptemberi indexe a #10 helyre teszi a Rustot, az egy évvel korábbi #18 helyről, és túl azon a #13 helyen, amelyet a TIOBE januárban minden idők legjobb helyezésének nevezett.
Az én olvasatom: a megtorpanás valós volt. Légzsák volt, nem plafon. Ez jobb, mint bármelyik tábor verziója, mert „a Rust elakadt” mostanra téves, „a Rust csak felfelé megy” pedig soha nem volt igaz.
A fenntartás mindkét irányba vág, és a Slashdot cikke már akkor felvetette: lehet, hogy a rangsorok csak ingadoznak a keresőmotorok találatainak hónapról hónapra jelentkező zaja miatt, hiszen az index ezt számolja. Ha egy negyedév alatti háromhelyes esés gyenge bizonyíték volt arra, hogy a Rust lassul, akkor egy hathelyes emelkedés ugyanilyen gyenge bizonyíték arra, hogy nyer. Kezeld időjárásként, ne éghajlatként.
A hangulatról erősebb jelzést ad a Stack Overflow felmérése, ahol a Rust ismét a legcsodáltabb programozási nyelv lett 2025-ben 72%-kal: azok, akik az elmúlt évben használták, és továbbra is használni szeretnék. Ez a további használat szándéka, nem az elterjedtség, és itt hasznosabb jelzés a puszta népszerűségnél, ha azt mérlegeled, élvezni fogod-e, ha kitartasz a nyelv mellett.
A lendület kétértelmű, és kisebb súlyt adok neki, mint a fenti tartósságnak, mert nem egy rangsorba fektetsz.
Mibe kerül neked a Rust megtanulása
A költség korán jelentkezik, és egyszerre. Az a kód, amelyet a Python, a Java vagy a C# boldogan lefuttatna, újra és újra elutasításra kerül olyan okokból, amelyek önkényesnek tűnnek, amíg a tulajdonlási modell össze nem áll a fejedben, és ezt nem lehet elhalasztani. A borrow checkeren nem tudod átszállítani magad úgy, ahogy át tudod szállítani magad azon, hogy nem érted teljesen az ORM-edet.
Ez az a rész, ami meglepett, és pont fordítva működik, mint várnád. Az r/rust „Struggling to learn Rust” szálában a legtöbb visszhangot kapott válasz a problémát a szokatlanság, nem a nehézség kérdéseként fogalmazza újra, és a szál a szemétgyűjtős nyelvekből érkező tapasztalt fejlesztőket nevezi meg úgy, mint akiknek nehezebb dolguk van. u/Voxelman egyszerűen fogalmaz: „A Rust nem nehéz. Hanem más.” Ugyanebben a szálban leírja a saját útját: C64 Basic, aztán egy sor imperatív nyelv, és egy első találkozás a Rusttal, amely „minden volt, csak nem WOW”, mert a régi szokások levetkőzése eltartott egy ideig.
Ilyen a számla. Ha nyolc éve írsz Pythont, nem egy szabályrendszert tanulsz meg, hanem egy feltevésrendszert adsz fel arról, hogy ki takarít utánad. Aki kevesebbet tud, annak kevesebbet kell elfelejtenie.
Egy másik minta is többször felbukkan abban a szálban, és egy sorrendi hibából önbizalomproblémát csinál: az emberek nem a Rustnál akadnak el, hanem egy webes keretrendszer kiválasztásánál, amikor az Axumon vagy az Actixen keresztül próbálják megtanulni a nyelvet, mielőtt a tulajdonlás leesett volna. Ahogy u/jmartin2683 fogalmazott, ez „olyan, mintha a rubyt a rails megtanulásával próbálnád megtanulni.”
A költségekről szóló figyelmeztetések többségét úgy látom, hogy rossz dologra mutatnak. Tartós gyakorlással számolj, ne egy hétvégével, és a korai frusztrációt ne tekintsd ítéletnek a képességeidről.
A Rust fordításához nagyobb gép kell, mint a futtatásához
Ez az az eredmény, amire nem számítottam: ennek a Rust-projektnek a fordítása nagyságrendekkel több memóriát igényelt, mint a futtatása. Építettem egy kis Axum-szolgáltatást (Tokio a full funkciókészlettel, serde, serde_json, tower, egy JSON-útvonal, nagyjából 60 crate a függőségi fában) rustc és cargo 1.98.1 alatt, a strip = true beállítással a release profilban, majd kétszer lefordítottam tiszta állapotból:
# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --releaseEgyetlen fordítási feladatra korlátozva (--jobs 1) a cargo, a rustc és a linker csúcsmemóriája 464 MB és 527 MB között alakult attól függően, hogy a két mérési módszerem közül melyiket nézed (azért mértem kétféleképpen, mert az első szám túl szépnek tűnt), és 113 másodpercig tartott. Alapértelmezett párhuzamossággal négy vCPU-n a csúcsmemória nagyjából megduplázódott, körülbelül 1 GB-ra, és a fordítás körülbelül 35 másodperc alatt lefutott. Itt a párhuzamosság a változó, nem a projekt. Több feladat több egyszerre memóriában lévő rustc-folyamatot jelent, ezért a fordítók azon kevés terhelés közé tartoznak, amelyek boldogan elvesznek minden magot, amit adsz nekik, akár perceken át.
A kész program strip után 1,3 MB, és üresjáratban nagyjából 3,3–3,6 MB memóriát használ.
Alapértelmezett párhuzamosságnál ez kétszáz-háromszázszor több memória a fordításhoz, mint a futtatáshoz; egy feladatra korlátozva is jóval több mint százszoros. Ha a szervert ahhoz méretezed, amire a Rust-szolgáltatásodnak élesben szüksége van, könnyen olyan gépet kaphatsz, amely nem tudja lefordítani, és a hiba nem egy tiszta hibaüzenet: hanem az out-of-memory killer, amely fordítás közben kilövi a rustc-t, vagy egy fordító, amely húsz percig a swapot gyötri. Két megoldás működik. Fordíts valahol, ahol van tartalék, és szállítsd a binárist, ugyanaz a minta, mint egy külön build gép fenntartása nehéz Docker-munkához. Vagy fordíts a gépen, és adj neki helyet: egy ilyen felépítésű szolgáltatáshoz pár gigabájt RAM és két vCPU kényelmes. Ha nem az, a vészkijárat a --jobs 1 (igen, lassabb; ez az ára).
Ha a gépen, amelyen dolgozol, nincs ekkora tartalék, a mi saját kezelésű Linux VPS-ünk root hozzáférést ad óránkénti vagy havi számlázással, és helyet ad a fordításnak, amelyet visszaadhatsz, ha végeztél, bár ez továbbra is egy általad üzemeltetett szerver, nem pedig olyan, amely önmagát üzemelteti.
Egy projekt, egy felépítés, egy gép. A gép egy megosztott, izolált konténer volt, nem dedikált szerver, nagyjából 2 GB elérhető memóriával, így a korlátozás nélküli csúcs közelebb járt a plafonjához, mint egy nagyobb gépen. Ezek nem univerzális állandók: ha a függőségi fád négyszer akkora, vagy a release profilod bekapcsolja a linkeléskori optimalizálást, más számokra számíts. A nagyobb függőségi fák, a linkeléskori optimalizálás és a genericsekkel teli kód feljebb tolhatja a fordítási memóriát, úgyhogy ne kezeld a méréseimet univerzális plafonként.
Ezt ahhoz sorolnám, hogyan dolgozol, nem ahhoz, hogy megtanulod-e a nyelvet. Tudj róla, mielőtt belefutsz.
Kinek érdemes megtanulnia a Rustot
Három helyzet, amelyben azt mondanám, hogy szánd rá az időt: hosszú életű szoftver, ahol egy memóriahiba drága, az operációs rendszerhez közeli munka, és ha arra vágysz, amit a fordítóval való küzdelem tesz a memóriáról való gondolkodásoddal. Mindegyiknél megvan az oka, hogy az idő megtérül.
Már szállítasz szoftvert egy másik nyelven, és valami hosszú életűt építesz, ahol egy memóriahiba drága lenne. Egy szolgáltatás, amelynek működnie kell. Egy könyvtár, amelytől más csapatok függenek. Bármi, ahol egy use-after-free incidensvizsgálatot jelent, nem egy stack trace-t a terminálodban. Ez az az eset, amelyre az egész garanciát tervezték, és amit előre kifizetsz, az annak a teljes élettartama alatt térül meg, amit építesz.
Rendszerszoftverek közelében vagy azokon belül dolgozol. Illesztőprogramok, eszközökkel kapcsolatos munka, alaprendszer-segédprogramok, beágyazott rendszerek, bármi, ami egy operációs rendszer alatt ül, nem pedig rajta. Az iparág itt olyan módon kötelezte el magát, ahogy máshol nem, és a memóriabiztonsági bizonyítékok itt a legerősebbek.
A mellékhatásra vágysz. Abban az r/rust szálban két hozzászóló teljesen másként látja a Rust karrierértékét, mégis ugyanoda jutnak ebben. u/tyler_church, aki szerint semmilyen hatással nem volt a karrierjére, azért elismeri, hogy „talán finoman befolyásolja, hogyan írok más programokat más nyelveken.” u/SirKastic23, aki két éve kap fizetést azért, hogy Rustot írjon, azt mondja, hogy olyan módon szélesítette a programozási készségeit, amire sosem számított. Két ember, nem egy tanulmány, de ez az a haszon, amely akkor is megmarad, ha soha nem írsz Rustot hivatásszerűen: a gondolkodásod változása, nem egy sor az önéletrajzodban.
Kinek nem érdemes megtanulnia a Rustot
Három helyzet, amelyben ezt az időt jobb máshová fordítani: ebben a hónapban határidőd van, most tanulsz egyáltalán programozni, vagy aszerint választasz nyelvet, hány álláshirdetés említi. A harmadikról kérdeznek a legtöbben.
Ebben a hónapban határidőd van egy CRUD-alkalmazásra vagy egy prototípusra. A Rust pont rossz ütemezéssel érkezik egy olyan munkához, amelynek péntekre léteznie kell. Ha fordított nyelvet szeretnél gyors fordítással és szemétgyűjtős memóriakezeléssel, és nincs szükséged a Rust tulajdonláson alapuló garanciáira, a kézenfekvő választás helyette a Go.
Most tanulsz egyáltalán programozni. Ez tényleg megosztja azokat, akik Rustból élnek, és az r/rust szálakban a vita mindkét irányba zajlik, úgyhogy az én álláspontom az, hogy egy kezdő kezébe pénzfeldobást adni rossz tanács, akárhogy is esik a pénz. Előbb egy megbocsátóbb helyen tanuld meg, hogyan működik egy gép, aztán gyere vissza, és hagyd, hogy a fordító megszorítsa.
Aszerint választasz nyelvet, hány álláshirdetés említi. Itt nem adok számot, mert nem találtam olyan fizetési vagy álláshely-adatot a Rustra, amely egy általam védhető forrásra vezethető vissza. Amit u/crusoe abban az r/rust szálban leír, az egy kevesebb, de specializáltabb pozíciót kínáló piac. Ez egy hozzászóló egy szálban, nem munkaerőpiaci adat, így nem csinálnék belőle olyan állítást, hogy a Rust-állások általánosan ritkák. Ha az állások száma a döntő tényező számodra, nézd meg a célpiacod aktuális hirdetéseit, mielőtt nyelvet választasz.
Gyakran ismételt kérdések
Ingyenes a Rust?
Igen. A nyelv és a hivatalos projektjei általában kettős licencűek az MIT licenc és az Apache License 2.0 alapján, a toolchain pedig ingyen telepíthető a rustup segítségével. Nincs fizetős csomag, és nincs megvásárolandó kereskedelmi licenc.
Mennyi idő alatt lehet megtanulni a Rustot?
Ha már programozol, a szintaxis általában a könnyű rész. A tulajdonlás és a kölcsönzés tovább tart, mert megváltoztatják, hogyan gondolkodsz a memóriáról, az élettartamok és az aszinkron Rust pedig később újabb réteget adnak hozzá. Nem találtam védhető, általános idővonalat, ezért nem mondanék rá számot.
Jó első programozási nyelv a Rust?
Szerintem nem, de tudnod kell, hogy a kérdés vitatott a tapasztalt gyakorló fejlesztők között. Az r/rust „Struggling to learn Rust” szálában u/cassepipe kereken kijelenti, hogy a Rust „nem jó első nyelv”, miután lepattant róla, és a C-n és a C++-on keresztül tért vissza, míg u/Voxelman az ellenkezőjét állítja: az imperatív nyelvek rossz kiindulópontok, mert olyan szokásokra tanítanak, amelyeket aztán le kell vetkőzni. Ugyanez a vita négy oldalon át folyik a Rust saját felhasználói fórumán. Nincs kialakult közösségi válasz, amelyről be lehetne számolni.
Leváltja a Rust a C++-t?
Nem. A Rustot a C és a C++ mellé adják hozzá, és konkrét új komponensekhez választják, ami más dolog. A Linux kernelben a Rustot a meglévő C-kódbázis mellé adják hozzá, ahelyett hogy teljes egészében lecserélnék. Az Androidnál a Google kinyilvánított megközelítése az, hogy az új kódot memóriabiztos nyelveken írják, ahelyett hogy a meglévő C és C++ kódot átírnák. Hosszú együttélésre számíts.
Gyorsabb a Rust, mint a Go?
Ezt nem mértem le, ezért nem állítom, hogy az egyik kategorikusan gyorsabb. A Rust finomabb irányítást ad a memóriafoglalás felett, és nem igényel szemétgyűjtőt; a Go szemétgyűjtős futtatókörnyezetet használ, és az alacsony szintű irányítás egy részét az egyszerűbb fejlesztésért cseréli el. Hogy melyik a gyorsabb, az a terheléstől, a megvalósítástól és a szűk keresztmetszettől függ, ezért olyan benchmarkokat használj, amelyek a saját alkalmazásodra hasonlítanak.
Beszélgetés
Hozzászólások
Jelentkezzen be a beszélgetéshez.