Anmeldelse af programmeringssproget Rust: Er det værd at lære?

Spørg to erfarne Rust-udviklere, om det var besværet værd at lære Rust, og du kan få helt modsatte svar. Den ene siger måske, at det intet gjorde for karrieren; den anden kalder det måske en af de bedste tekniske beslutninger, vedkommende har truffet. Begge kan have ret.

Det er i den modsigelse, spørgsmålet „er Rust værd at lære“ egentlig ligger, og det er derfor, et generelt ja er ubrugeligt for dig. Rust er et kompileret sprog, hvis sikre delmængde håndhæver regler for hukommelsessikkerhed på kompileringstidspunktet, uden at kræve en garbage collector under kørsel.

Så jeg lægger mig fast på et svar, nævner den betingelse, det hænger på, og viser dig, hvad betingelsen koster.

Den korte version

Rust er værd at lære, hvis du bygger noget langlivet, hvor det er værd at betale for, at compileren fanger en hel klasse af fejl. Det er det forkerte valg, hvis du skal levere en CRUD-app denne måned, er ved at lære at programmere eller tæller jobopslag. 4 ud af 5, med fradrag for det, det koster, før det betaler sig.

• Det, du køber: i sikker Rust gør reglerne for ownership og borrowing use-after-free-, double-free-, invalid-reference- og data race-fejl til kompileringsfejl i stedet for produktionshændelser. Det er hele salgsargumentet, og det er et godt et.
• Det, du betaler: compileren får dig til at skrive hukommelsesbeslutninger ned, som dit nuværende sprog træffer i stilhed, og i starten føles det, som om værktøjet er besværligt.
• Spørgsmålet om holdbarhed er afgjort. Kernens maintainere afsluttede Rust-eksperimentet på Maintainers Summit i december 2025, og mærkatet „eksperimentel“ forsvandt i Linux 7.0.
• Spørgsmålet om popularitet er ikke afgjort, og det er et andet spørgsmål. Rust ligger som #10 i TIOBE-indekset for september 2026, op fra #18 et år tidligere.
• Min Rust-testservice krævede langt mere hukommelse for at kompilere end for at køre: den toppede tæt på 1 GB under bygning og lå i tomgang på omkring 3,5 MB, når den kørte.
• Rigtigt for dig, hvis du allerede leverer i et andet sprog og bygger noget, hvor en hukommelsesfejl ville være dyr, eller du arbejder tæt på systemsoftware. Forkert for dig, hvis du har en deadline, starter fra nul eller leder efter sproget med flest ledige stillinger.

Sådan blev denne anmeldelse lavet: bygge- og kørselstallene her er mine egne. Jeg installerede Rust 1.98.1, skrev en lille Axum-webservice og målte, hvad det krævede at kompilere den, og hvad det krævede at køre den. Det kørte i en sandboxet container, ikke på dedikeret hardware, og det er ét projekt, så betragt tallene som et datapunkt og ikke som en lov. Alt andet kommer fra primære eller autoritative kilder: kernepatchen og LWN's dækning af den, Googles sikkerhedsindlæg om Android, TIOBE's eget indeks (med kommentaren fra april via Slashdots gengivelse af den), Phoronix om merge-vinduet for Linux 7.0, Linux-kernens CVE-registreringer for Binder-sårbarheden, Canonicals egen udtalelse og Stack Overflow-undersøgelsen fra 2025. Jeg læste kernepatchen. Jeg har ikke auditeret Rust-koden i kernen. Og jeg har ikke skrevet Rust i årevis, så hvor denne anmeldelse bedømmer selve sproget, læner den sig op ad praktikere, der har, og nævner dem ved navn.

Hvad compileren giver dig

Giv to tråde en muterbar reference til den samme vektor i Rust, og koden kompilerer ikke. Ikke en advarsel. Ikke en lint, du kan slå fra, når deadline presser. Den bygger ikke. Den afvisning er det, du køber i sikker Rust: use-after-free-, double-free-, invalid-reference- og data race-fejl bliver skubbet over i kompileringsfejl i stedet for produktionshændelser. Rusts nødudgang (unsafe) kan omgå nogle af de garantier, så dette er ikke et absolut løfte om enhver Rust-kodebase.

Ownership betyder, at hver værdi har præcis én ejer, der er ansvarlig for at frigive den. Borrowing betyder, at du kan låne referencer ud, men compileren holder styr på deres levetid og lader ikke en af dem overleve det, den peger på, eller lader et muterbart lån eksistere side om side med noget andet. I sikker Rust bliver use-after-free-, double-free-, invalid-reference- og data race-fejl fanget af ownership- og typesystemet, før programmet kører.

Der er ingen garbage collector, og det er den anden halvdel af aftalen. Fordi ownership allerede fastlægger, hvem der frigiver hvad og hvornår, behøver intet at gennemsøge din heap under kørsel. Du leverer en binær fil uden collector i, og du får ingen pausetider, du skal tune dig uden om.

Prisen viser sig samme sted som garantien. Hver hukommelsesbeslutning, dit nuværende sprog stille træffer på dine vegne, beder Rust dig skrive ned: hvem ejer det her, hvor længe lever den reference, kan noget andet se den, og krydser den en trådgrænse. Compileren er ikke besværlig. Den nægter at gætte.

Så: det her er grunden til, at nogen overhovedet betaler det, Rust beder om, og jeg synes, den holder. Hvis den klasse af fejl, det fjerner, ikke er en, du bekymrer dig om, ændrer resten af denne anmeldelse nok ikke din mening.

Er Rust stadig eksperimentelt, eller er det produktionsinfrastruktur nu?

Det holdt op med at være eksperimentelt i december 2025, og dem, der afsluttede det, var kernens maintainere selv. På Maintainers Summit 2025 konkluderede de, at Rust havde båret sin egen vægt i kernen, teknisk og socialt. LWN's Jonathan Corbet rapporterede konsensus den 10. december 2025: Rust i kernen er ikke længere eksperimentelt.

Rust kom ind i mainline Linux med v6.1 i 2022 netop for at køre det eksperiment. Miguel Ojedas patch, der fjernede mærkatet, fulgte tre dage efter topmødet, og den kom med i merge-vinduet for Linux 7.0.

„Men eksperimentet er slut, dvs. Rust er kommet for at blive.“

Miguel Ojeda, „rust: conclude the Rust experiment“, LKML, 13. december 2025

Separat, og tidligere: Googles Rust-omskrivning af Androids Binder-driver, det IPC-lag, som Androids processer taler gennem (konstant), landede i Linux 6.18, der udkom den 30. november 2025. Hold den milepæl adskilt fra konsensus på topmødet. Det er den, hvor et firma satsede et produkt, der rent faktisk leveres, på kerne-Rust, ikke en gruppe maintainere, der velsignede idéen. Kerne-Rust har siden fået sin første CVE: CVE-2025-68260, en race condition i den samme Binder-driver, som Greg Kroah-Hartman annoncerede den 16. december 2025, introduceret i 6.18 og rettet i 6.18.1. De første rapporter fokuserede på nedbrud, men Linux-kernens CVE-teams senere vurdering sætter CVE-2025-68260 til 7,8 (High) og beskriver en lokal vej til rettighedseskalering gennem hukommelseskorruption i kernen. Den samme driver (rust_binder) har siden også samlet flere CVE'er.

Det er i Android, at beviserne bliver talmæssige. Googles sikkerhedsblog oplyste i december 2022, at der var fundet nul sårbarheder i hukommelsessikkerheden i Androids Rust-kode, målt mod cirka 1,5 millioner linjer Rust i AOSP og omkring 21 % af al ny native kode i Android 13. Det er en udtalelse fra 2022 med et omfang fra 2022. Googles senere indlæg viser den længere tendens: problemer med hukommelsessikkerhed stod for 76 % af Androids sårbarheder i 2019 og 24 % i 2024, hvor det rå antal faldt fra over 220 til forventet 36. De tal betyder kun noget set i forhold til det udgangspunkt, de erstattede, nemlig C og C++ skrevet af meget dygtige ingeniører med meget godt værktøj.

To mindre signaler peger samme vej. GPU-driveren til Apple AGX i Asahi Linux er Rust, skrevet af Asahi Linux-projektet som reverse engineering og ikke af Apple. Canonicals opdatering om rust-coreutils siger, at Ubuntu 26.04 LTS leverer rust-coreutils 0.8.0 til de fleste værktøjer. Tre bliver på GNU coreutils (cp, mv, rm), fordi otte TOCTOU-problemer stadig var åbne den 22. april 2026; Canonical sigter mod 26.10 for de resterende værktøjer.

Det er den akse, jeg ville give den højeste score, og grunden er den slags forpligtelse, der er tale om. Kernens maintainere trækker ikke afsluttede eksperimenter tilbage, Google ruller ikke en omskrivning af den størrelse tilbage, og Canonical putter ikke en omskrevet coreutils i en LTS for at se, hvordan det går. Uanset hvad der sker med Rusts popularitet, skal nogen vedligeholde den kode i årevis.

Er Rust dødt, eller flader det bare ud?

Nej. Rust tangerede sin bedste TIOBE-placering nogensinde, #13, i januar 2026. Tre måneder senere var det faldet tilbage til #16, og TIOBE's CEO Paul Jansen skrev i april 2026, i en kommentar Slashdot citerede dengang, at Rusts vækst i popularitet „ser ud til at flade ud“, og at en top 10-placering „nu virker længere væk end før“.

Han beskrev, hvordan Rust nåede sin højeste placering nogensinde på hans eget indeks, en plads det først havde haft i juli 2024, og derefter gav den fra sig igen.

TIOBE's indeks for september 2026 placerer Rust som #10, op fra #18 et år tidligere, og forbi den #13, som TIOBE i januar kaldte sin højeste placering nogensinde.

Min læsning: plateauet var ægte. Det var et lufthul, ikke et loft. Det slår begge lejres version, for „Rust er gået i stå“ er nu forkert, og „Rust går kun op“ var aldrig sandt.

Forbeholdet skærer begge veje, og Slashdots artikel rejste det selv dengang: svinger placeringerne måske bare med månedlig støj i søgemaskineresultaterne, som er det, indekset tæller? Hvis et fald på tre pladser i et kvartal var tyndt bevis for, at Rust bremsede op, er en stigning på seks pladser tyndt bevis for, at det vinder. Brug det som vejr, ikke klima.

Det stærkere signal om stemningen er Stack Overflow-undersøgelsen, hvor Rust endnu en gang er det mest beundrede programmeringssprog i 2025 med 72 %: folk, der har brugt det det seneste år og vil blive ved med at bruge det. Det er et ønske om fortsat brug, ikke udbredelse, og det er et mere nyttigt signal her end rå popularitet, hvis du vil vurdere, om du vil nyde at blive ved sproget.

Momentum er tvetydigt, og jeg vægter det under holdbarheden ovenfor, for du investerer ikke i en placering.

Hvad det koster dig at lære Rust

Omkostningen lander tidligt og på én gang. Kode, som Python, Java eller C# gladeligt ville køre, bliver afvist igen og igen af grunde, der føles vilkårlige, indtil ownership-modellen falder på plads, og det kan ikke udskydes. Du kan ikke levere dig forbi borrow checkeren, sådan som du kan levere dig forbi ikke helt at forstå din ORM.

Her er den del, der overraskede mig, og den går den modsatte vej af, hvad man ville forvente. I r/rust-tråden „Struggling to learn Rust“ omformulerer det svar, der fik mest opbakning, problemet som uvanthed, ikke sværhedsgrad, og tråden peger på erfarne udviklere, der kommer fra sprog med garbage collection, som dem, der har det sværest. u/Voxelman siger det ligeud: „Rust er ikke svært. Det er anderledes.“ I samme tråd beskriver vedkommende sin egen vej ind: C64 Basic, derefter en række imperative sprog, og et første møde med Rust, der „var alt andet end WOW“, fordi det tog et stykke tid at lægge de gamle vaner fra sig.

Sådan ser regningen ud. Hvis du har skrevet Python i otte år, lærer du ikke et sæt regler, du opgiver et sæt antagelser om, hvem der rydder op efter dig. En, der ved mindre, har mindre at aflære.

Endnu et mønster dukker op gang på gang i den tråd, og det gør en fejl i rækkefølgen til et selvtillidsproblem: folk sidder ikke fast i Rust, men i at vælge et webframework, fordi de prøver at lære sproget gennem Axum eller Actix, før ownership har sat sig. Som u/jmartin2683 formulerede det, er det „som at prøve at lære Ruby ved at lære Rails.“

Jeg læser de fleste advarsler om omkostningen som rettet mod det forkerte. Sæt tid af til vedvarende øvelse, ikke en weekend, og læs ikke tidlig frustration som en dom over dine evner.

Rust kræver en større maskine at bygge på end at køre på

Her er det resultat, jeg ikke havde forventet: at bygge dette Rust-projekt krævede størrelsesordener mere hukommelse end at køre det. Jeg byggede en lille Axum-service (Tokio med full som feature-sæt, serde, serde_json, tower, én JSON-rute, omkring 60 crates i afhængighedstræet) på rustc og cargo 1.98.1, med strip = true i release-profilen, og byggede den derefter fra bunden to gange:

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

Begrænset til ét kompileringsjob (--jobs 1) lå spidsforbruget af hukommelse på tværs af cargo, rustc og linkeren mellem 464 MB og 527 MB, afhængigt af hvilken af mine to målemetoder man bruger (jeg målte det på to måder, fordi det første tal så for pænt ud), og det tog 113 sekunder. Med standardparallelisme på fire vCPU'er blev spidsforbruget cirka fordoblet til omkring 1 GB, og buildet blev færdigt på omkring 35 sekunder. Det er paralleliteten, der er variablen, ikke projektet. Flere jobs betyder flere rustc-processer i hukommelsen på én gang, og derfor er compilere en af de få workloads, der gerne tager hver eneste kerne, du giver dem i minutter ad gangen.

Det færdige program fylder 1,3 MB strippet og bruger i tomgang omkring 3,3 til 3,6 MB hukommelse.

Ved standardparallelisme er det to til tre hundrede gange mere hukommelse at kompilere end at køre; begrænset til ét job er det stadig et godt stykke over hundrede gange. Dimensionér en server efter, hvad din Rust-service skal bruge i produktion, og du kan ende med en maskine, der ikke kan bygge den, og fejlen er ikke en pæn fejlmeddelelse: det er out-of-memory-killeren, der skyder rustc ned midt i buildet, eller en compiler, der kører swap i tyve minutter. To løsninger virker. Byg et sted med luft og send den binære fil ud, samme mønster som at holde en separat build-maskine til tungt Docker-arbejde. Eller byg på maskinen og giv den plads: til en service af denne type er et par gigabyte RAM og to vCPU'er behageligt. Når det ikke er muligt, er nødudgangen --jobs 1 (ja, det er langsommere; det er prisen).

Hvis den maskine, du arbejder på, ikke har den luft, giver vores selvadministrerede Linux VPS dig root-adgang med afregning pr. time eller pr. måned og et sted at lægge buildet og aflevere det igen, når du er færdig, selvom det stadig er en server, du selv driver, og ikke en, der driver sig selv.

Ét projekt, én form, én maskine. Maskinen var en delt, sandboxet container, ikke en dedikeret server, med omkring 2 GB tilgængelig hukommelse, så spidsbelastningen uden begrænsning lå tættere på loftet, end den ville på en større maskine. Det er ikke en universel konstant: hvis dit afhængighedstræ er fire gange så stort, eller din release-profil slår link-time optimization til, så forvent andre tal. Større afhængighedstræer, link-time optimization og kode med mange generics kan presse byggehukommelsen højere, så betragt ikke mine målinger som et universelt loft.

Jeg vil placere det under, hvordan du arbejder, ikke om du skal lære sproget. Kend til det, før du rammer det.

Hvem bør lære Rust

Tre situationer, hvor jeg ville sige, du skal bruge tiden: langlivet software, hvor en hukommelsesfejl er dyr, arbejde, der ligger tæt på styresystemet, og hvis du vil have det, som kampen med compileren gør ved din måde at tænke hukommelse på. Hver af dem har en grund til, at tiden betaler sig tilbage.

Du leverer allerede i et andet sprog og bygger noget langlivet, hvor en hukommelsesfejl ville være dyr. En service, der skal blive oppe. Et bibliotek, som andre teams afhænger af. Alt, hvor en use-after-free betyder en incident review og ikke en stack trace i din terminal. Det er netop den situation, hele garantien blev bygget til, og det, du betaler på forhånd, afskrives over levetiden af det, du bygger.

Du arbejder tæt på eller inde i systemsoftware. Drivere, arbejde med enheder, basissystemværktøjer, embedded, alt, der ligger under et styresystem i stedet for oven på et. Branchen har forpligtet sig her på en måde, den ikke har andre steder, og beviserne for hukommelsessikkerhed er stærkest her.

Du vil have bivirkningen. To kommentatorer i den r/rust-tråd er helt uenige om Rusts karriereværdi og lander samme sted her. u/tyler_church, der siger, at det havde nul betydning for karrieren, indrømmer stadig „måske subtile påvirkninger af, hvordan jeg skriver andre programmer i andre sprog“. u/SirKastic23, der i to år har fået løn for at skrive Rust, siger, at det udvidede vedkommendes kodefærdigheder på måder, der aldrig var forventet. To mennesker, ikke en undersøgelse, men det er gevinsten, der består, selv hvis du aldrig skriver Rust professionelt: en ændring i, hvordan du tænker, ikke en linje på et CV.

Hvem bør ikke lære Rust

Tre situationer, hvor tiden er bedre brugt andetsteds: du har en deadline denne måned, du er overhovedet ved at lære at programmere, eller du vælger sprog efter, hvor mange jobopslag der nævner det. Det tredje er det, folk spørger mest om.

Du har en deadline denne måned på en CRUD-app eller en prototype. Rust kommer på præcis den forkerte tidsplan til arbejde, der skal eksistere på fredag. Go er det oplagte at gribe efter i stedet, hvis du vil have et kompileret sprog med hurtige builds og hukommelsesstyring med garbage collection, og du ikke har brug for Rusts ownership-baserede garantier.

Du er overhovedet ved at lære at programmere. Det her splitter virkelig folk, der skriver Rust for at leve, og uenigheden i r/rust-trådene går begge veje, så min holdning er, at det er et dårligt råd at give en nybegynder plat eller krone, uanset hvilken side mønten lander på. Lær først, hvordan en maskine fungerer, et sted, der er mere tilgivende, og kom så tilbage og lad compileren stramme det op.

Du vælger sprog efter, hvor mange jobopslag der nævner det. Jeg giver dig ikke et tal her, fordi jeg ikke kunne finde et løn- eller stillingstal for Rust, der kan spores til en kilde, jeg ville forsvare. Det, u/crusoe beskriver i den r/rust-tråd, er et marked med færre og mere specialiserede stillinger. Det er én kommentator i én tråd, ikke arbejdsmarkedsdata, så jeg ville ikke gøre det til en påstand om, at Rust-job generelt er sjældne. Hvis antallet af job er det afgørende for dig, så tjek de aktuelle opslag på dit målmarked, før du vælger sproget.

Ofte stillede spørgsmål