Rust start eigen platform voor opensourceprojecten Rust Innovation Lab

The Rust Foundation kondigt het ondersteuningsplatform Rust Innovation Lab aan. Op dit platform worden gefinancierde Rust-projecten ondergebracht en op verschillende manieren ondersteund.

Volgens de non-profitorganisatie is het platform bedoeld voor haar opensourceprojecten op basis van de Rust-programmeertaal. Het platform biedt 'fiscale sponsoring van goed gefinancierde projecten' vanuit de organisatie. Deze sponsoring bestaat onder meer uit ondersteuning bij de governance van een project, maar ook bij marketing, administratie en juridische zaken. Het voordeel is volgens de organisatie dat ontwikkelaars geen aparte stichting hoeven op te zetten om bijvoorbeeld donaties te kunnen ontvangen.

Het doel van het platform is volgens de organisatie om het Rust-ecosysteem verder te verbeteren. Volgens de organisatie is het Rust Innovation Lab een neutrale omgeving waar de projecten onder controle staan van de 'maintainers' van het project.

Het eerste project dat via Rust Innovation Lab ondersteuning krijgt is Rustls. Dit opensourceproject moet een memorysafe TLS-library bieden. Het is niet duidelijk hoeveel andere projecten het RIL kan ondersteunen en op welke schaal.

Reacties (28)

[davekok]

Voelt een beetje als de begin jaren van Java. Alles moet Java worden. Dus laten we proberen iedereen Java te laten programmeren en alle investeringen rond te krijgen dat voor alles een Java library komt.

Zou het niet verstandiger zijn om aan standaarden te gaan werken voor programmeertalen. Waar een programmeertaal minimaal aan moet voldoen. En te forceren desnoods vanuit de overheid dat programmeertalen daar aan moeten gaan voldoen.

[annejouke]

Wat een raar inzicht / bizarre mening.

Overheden zouden moeten bepalen wat een programmeertaal moet kunnen? Dat is echt de beste manier om alle innovatie de nek om te draaien. Wat is toch die bizarre obsessie om alles maar door overheden te laten regelen als het ons even niet aanstaat. Hebben overheden inmiddels niet bewezen compleet incompetent te zijn m.b.t. techniek en inovatie?

Bovendien is er geen enkele manier om dit te forceren. Zou Github alle repo's moeten scannen om te kijken of er ook iets gedaan wordt dat lijkt op een programmeertaal, en als het niet aan de standaarden voldoet, de repo flaggen om te wissen?

Ik vind Rust een vreselijke taal om in te programmeren en ben beslist geen fanboy van deze taal, maar wat ze proberen te doen is echt wel heel wijs: een low-level taal maken die zorgt dat niet al die gaten die assembly, C en C++ wel laten vallen proberen, zo goed mogelijk, te dichtten. Het is niet perfect, maar het is sowieso 10x beter.

Dit gaat er voor zorgen dat operating systems, drivers, frameworks, runtimes en libraries een stuk beter bewaakt zijn tegen typische bugs en veiligheidslekken. Het is niet onmogelijk om dit in Rust te doen. Als iemand als Linus Torvalds al heil ziet in het adopteren van een tweede taal in zijn geliefde kernel (de slechtste keuze die je kan maken - twee codebases hanteren), dan is het ECHT de moeite wel waard.

Dus het is zeker een goed idee om een groot deel van de bouwblokken van onze moderne digitale maatschappij, die nu krampachtig in C, C++ en andere talen gebouwd worden en naar het beste inzicht van de developer beveiligd worden, te herschrijven in Rust.

[djc]

Overheden zouden moeten bepalen wat een programmeertaal moet kunnen? Dat is echt de beste manier om alle innovatie de nek om te draaien. Wat is toch die bizarre obsessie om alles maar door overheden te laten regelen als het ons even niet aanstaat. Hebben overheden inmiddels niet bewezen compleet incompetent te zijn m.b.t. techniek en inovatie?

Het zou wmb niet zo gek zijn als overheden meer zouden doen om vulnerabilities tegen te gaan. De impact van security breaches is nu vaak moeilijk vooraf te kwantificeren waardoor er weinig incentive is voor bedrijven om te investeren in veiligheid. Lijkt mij niet gek als overheden zeggen dat je geen C of C++ meer moet gebruiken voor software die wordt blootgesteld aan het publieke internet, bijvoorbeeld.

Ik vind Rust een vreselijke taal om in te programmeren en ben beslist geen fanboy van deze taal, maar wat ze proberen te doen is echt wel heel wijs: een low-level taal maken die zorgt dat niet al die gaten die assembly, C en C++ wel laten vallen proberen, zo goed mogelijk, te dichtten. Het is niet perfect, maar het is sowieso 10x beter.

Ben wel benieuwd wat je er zo vreselijk aan vindt. Ik ben er in 2016 mee begonnen en wil niet anders meer.

[annejouke]

Wat jij voorstelt is tenminste nog te toetsen. Dan moet het of een GC taal worden of Rust - of iemand maakt een alternatief op Rust.

Rust is voor mijn use-cases niet prettig. Ik wil business requirements documenteren, of de regels van een user interface helder kunnen opgeven. Gebruiker mag dit wel, dat niet. Dat kan wel in Rust, maar je moet bij Rust allemaal "vertel de computer wat hij moet doen" logica in het type-systeem proppen, dat maakt de syntax heel wollig. Daar zijn GC talen / script talen veel prettiger. Dat het tig keer meer CPU/RAM kost t.o.v. Rust maakt het verschil niet voor businesses, dat de developer de regels snel aan kan passen wel.

[Mellow Jack]

Is hetgeen wat jij bedoelt niet het verschil tussen high level en low level programmeren? Niet perse een vergelijking tussen rust en een vergelijkbare taal?

[Jeanpaul145]

Naja Rust is dan ook een systems programming taal. De focus daar ligt op het veilig kunnen programmeren van systemen, en niet op business logic of UIs.

Dus in zekere zin is Rust gebruiken voor zulke zaken een schroevendraaier gebruiken om een spijker in een muur te slaan en je dan afvragen waarom het zoveel moeite kost. Daar was dit stuk gereedschap nooit echt voor bedoeld.

[ComputerGekkie]

Of, wat een goede eerste stap zou zijn, als overheid zeggen dat je geen software meer wilt hebben die geschreven is in niet memory safe talen die een bepaalde kwaliteitsstandaard moeten hebben. Dus bijvoorbeeld een belastingdienst moet zijn vingers afhouden van C++ en de likes, maar een gemeente website mag prima een beetje in PHP rommelen. Er zijn natuurlijk legio stappen tussen de 2 uitersten helemaal geen C en geen enkele kwaliteitsstandaard hebben. Ik merk dat Tweakers hier dat nog wel eens missen.

[BugBoy]

Vrijwel de hele Linux kernel is C/C++ en als je die niet meer aan het internet mag hangen, dan zal er niet veel meer werken.

Oudere talen (zoals C/C++) zijn inderdaad meer vatbaar voor security problemen, maar laten we niet doen alsof Rust geen security issues heeft. Problemen als buffer overruns, shared data, ... zullen veel minder zijn, maar het probleem zit niet altijd in de taal. Soms zijn bepaalde algoritmes gewoon niet veilig en daar zal geen enkele taal je tegen beschermen.

Het grooste probleem met security issues is dat er niet tijdig gepatcht wordt. Ook zie ik bij enterprises vaak bizarre security regels. Zo sprak ik laatst met een bedrijf dat bizarre beveiligingsregels had, maar toen ik in de configuratie LDAP zag zonder TLS bleek dat ze dat al jaren deden. Daar hadden ze een uitzondering voor gemaakt. Wel moeilijk doen over het opslaan van een hostname (niet extern toegankelijk), maar wel credentials plain-text over de lijn sturen. Is welliswaar een private LAN, maar toch. En zo zie ik het vaker. Hetzelfde bedrijf stelt SSE-C verplicht. Daarmee beheert de client de sleutel, maar stuurt die naar de server voor elk request. Kan je beter SSE-KMS doen, zodat je enkel een attack-surface hebt op de server ipv op allebei.

Het "probleem" van Rust is met name de steile leercurve. Met name het "ownership" model maakt het vaak lastig om over te schakelen van een taal als C/C++/Go naar Rust. Door dat model is het juist veiliger, maar als je begint met Rust dan ben je vooral bezig dit soort zaken op te lossen. Daarbij is de compilatietijd ook best lang t.o.v. Go. Voor minder spannende zaken vind ik Go veel vlotter en pragmatischer werken. Wil je echt veiligheid en het laaste beetje performance eruit halen, dan is Rust inderdaad onverslaanbaar.

Een ander nadeel van Rust fanboys is dat ze het bijna als een religie zien. Kritiek op Rust en je krijgt nog net geen fatwa ;)

[djc]

Vrijwel de hele Linux kernel is C/C++ en als je die niet meer aan het internet mag hangen, dan zal er niet veel meer werken.

Rust for Linux is een ding, net als Redox OS. Google's Fuchsia heeft een C/C++ microkernel met veel van de system services in Rust. Maar ja, het zal nog wel wat tijd kosten voordat de hele stack in Rust geschreven is. Ik denk zelf wel dat het waarschijnlijk die kant op gaat.

Oudere talen (zoals C/C++) zijn inderdaad meer vatbaar voor security problemen, maar laten we niet doen alsof Rust geen security issues heeft. Problemen als buffer overruns, shared data, ... zullen veel minder zijn, maar het probleem zit niet altijd in de taal. Soms zijn bepaalde algoritmes gewoon niet veilig en daar zal geen enkele taal je tegen beschermen.

Diverse grote bedrijven (MS, Google, en nog meer) hebben gezien dat 70% van de vulnerabilities te wijten zijn aan memory safety issues. Als je daar een structurele oplossing voor hebt is dat moeilijk te negeren.

(Ben het met je eens dat veel bedrijven rare dingen doen in het opereren van hun software.)

Het "probleem" van Rust is met name de steile leercurve. Met name het "ownership" model maakt het vaak lastig om over te schakelen van een taal als C/C++/Go naar Rust. Door dat model is het juist veiliger, maar als je begint met Rust dan ben je vooral bezig dit soort zaken op te lossen. Daarbij is de compilatietijd ook best lang t.o.v. Go. Voor minder spannende zaken vind ik Go veel vlotter en pragmatischer werken. Wil je echt veiligheid en het laaste beetje performance eruit halen, dan is Rust inderdaad onverslaanbaar.

[url="chttps://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html"]Volgens Google[/url] is de meerderheid van hun developers binnen 4 maanden productief in Rust. Valt met die steile leercurve dus ook wel mee.

Voor mijzelf is het niet eens borrowing maar met name traits en enums die echt een verschil maken in hoe robuust mijn Rust-code is.

[tkm]

I vind de rust hype een beetje overdreven. Net zoals toen Java werd gehyped als de taal.

Ik ben het er mee eens dat een taal een tool is en je moet de taal kiezen die bij de use case past.

Ik vind ook dat C++ een slechte naam krijgt als niet memory safe taal. Dat heeft meer met opleiding van de programmeur te maken dan met de taal.

[Powerblast]

De Rust programmeertaal is inderdaad overhyped. Het heeft interessante kenmerken en soms wel handige syntax maar qua readability vind ik het toch niet alles. Waarschijnlijk vergeleken met c++ nog niet zo extreem maar op een of andere reden leest c++ naar mijn ervaring toch beter.

Mij lijkt dat de taal als het enkel hype zou zijn binnen een paar jaar ofwel weg ofwel volledig stagneert. Als je kijkt naar bijvoorbeeld de pypl index gaat de adoption rate naar mijn mening toch wel traag, ook zou het volgens de community de heilige graal zijn. Time will tell denk ik. Maar als het niks is, sterft het vanzelfs zoals zovelen ervoor wel uit.

[Jeanpaul145]

Dat heeft meer met opleiding van de programmeur te maken dan met de taal.

Nee hoor. Een analoog argument uit de C/C++ kant is "just remember to clean up after yourself", maw voor elke allocatie moet je maar ff herinneren om dat ongedaan te maken.

Dat is het tegenovergestelde van waar de software wereld voor staat t.w. automatisering.

Het is ook gewoon compleet onrealistisch, wat o.a. aangetoond is door research van Google en MS wat aangeeft dat grofweg 70% van alle bugs exact zulke memory (de)allocation bugs zijn bv use-after-free, double-free, no-free etc.

En iedereen die langer meeloopt als software dev in C/C++ zal dat niet vreemd in de oren klinken, want ze hebben allemaal wel vaker met zulke bugs te maken gehad.


Mede hierom vind ik dan ook een claim als

Ik vind ook dat C++ een slechte naam krijgt als niet memory safe taal.

veel te kort door de bocht, C++ is namelijk niet memory safe. Het heeft constructs zoals smart pointers die het mogelijk maken te doen, maar net als bij de (de)allocation issues die ik aan 't begin van deze post bespreek is dat een kwestie van "niet vergeten te doen hé!". En daarmee is het op grotere schaal gewoon smeken om memory bugs, die vervolgens vrolijk geëxploiteerd worden door mensen met een minder vriendelijke agenda.


Met andere woorden: het mogelijk maken van memory safe programming in een taal is simpelweg niet voldoende voor systemen op enige (laat staan grote) schaal. Het moet de default zijn, met een gecontroleerde manier om daaruit te breken wanneer dat echt nodig is bv om performance redenen, of kernel level programming.

En laat dat nou net onderdeel zijn van de value proposition van Rust.

Dat Rust zo populair aan 't worden is is dus gebaseerd op merit (het heeft immers geen enorm bedrijf erachter om 't door de strot te drukken) gecombineerd met bittere lessen geleerd in 't verleden. Het gaat daarbij om de semantics van de taal, en niet om de syntax.

[Reactie gewijzigd door Jeanpaul145 op 6 september 2025 15:43]

[dwarfangel]

[quote]Hebben overheden inmiddels niet bewezen compleet incompetent te zijn m.b.t. techniek en inovatie?[/quote]

Dat is maar de vraag over welke overheid je het hebt? en ook over welke periode.

Ik denk dat jouw frustratie vooral leunt op de nederlandse politiek, waarin de tweede kamer een tragische poppenkast is geworden, waar wij allen dupe van zijn geworden. Die mening deel ik.

Dat betekent niet dat de overheid niet capabel zou moeten zijn op gebied van innovatie. In een goed kapitalistisch stelsel, zou innovatie een drijfveer moeten zijn voor groei. Waarbij nieuwe technieken, die gefinancierd en gesteund door de overheid nieuwe markten creeërt en het speelveld eerlijk houdt voor alle spelers, en niet alleen de happy few die toevallig genoeg geld hebben geerfd of vergaard en daardoor een loopje kunnen nemen met de rest.

Er worden immers ook standaarden gecreeërd voor USB-c laders. Waarbij ik dan wel benieuwd ben, of het beter vind dat alle appraten een eigen stekker gebruiken ?
In de software zie ik dat niet anders. Een overheid zou niet moeten bepalen wat een taal kan doen, lijkt me onmogelijk. Wat je wel kan doen, is een taal stimuleren en groeperingen stimuleren om de taal te ontwikkelen, en standaarden te ontwikkelen (het groene boekje) voor een programmeertaal.

[Ed Vertijsment]

Een overheid heeft over het algemeen weinig incentive om te innoveren want er hoeft geen geld verdient te worden, het kapitalistische karakter is er dan ook niet. Daarnaast wil bureaucratie dit ook nog wel eens afremmen. Van een afstandje willekeurig potjes geld uitdelen resulteert doorgaans alleen maar in subsidie trekkers.

We klagen over IT in de Nederlandse overheid maar ik hoor alleen maar soortgelijke verhalen (zo niet erger) van andere overheden.

Papieren tijgers opleggen aan nieuwe talen remt enorm en is ook niet wenselijk.

Het enige wat de overheid eigenlijk kan doen is in eigen aanbestedingen voorwaarden stellen aan features van een taal (bijvoorbeeld memory safe of soortgelijke bescherming) maar je moet dan oppassen dat je niet nodeloos bedrijven uitsluit.

[annejouke]

Ja @downtime maakt ook al een paar prachtige argumenten met een paar goeie voorbeelden. Misschien denk ik inderdaad wel teveel aan "politiek" en niet genoeg aan overheden. Ik heb zelf met rijkswaterstaat gewerkt, in ieder geval de afdelingen waar ik mee samen mocht werken, bizar professioneel en gedreven.

Ik zou er niet van uit gaan dat de standaarisering van USB-C 100% net benefit is. Ik dacht dat ook altijd tot een collega een paar knaller argumenten maakte waarom dat toekomstige innovatie ook prima kan beperken. Het is maar net wat je belangrijk vindt, ik vind het zelf ook niet prettig, dat idee van al die e-waste van al die apparaat specifieke stekkers.

Stimuleren, bevorderen of een soort standaard van veiligheid waar grotere applicaties, bedrijven en instanties aan moeten voldoen lijkt me een heel goed idee. Ik ben zeker niet zo'n "vrijheid over alles" gekkie, maar @davekok koos voor het woord "forceren" -- daarom moest ik een beetje tegengas geven

[davekok]

Als je context veranderd naar auto's. Vind je het dan nog steeds een raar inzicht / bizarre mening, als iemand zegt dat het standaardiseren van auto's, zoals veiligheidgordels?

[SPee]

Nou, het is wel een probleem als de overheid dingen gaat eisen die nog niet goed werken.

De nr1 klacht voor de huidige auto's? Al die "rijhulpsystemen" die niet goed werken en/of die je elke rit weer moet uitschakelen als je zonder wil. Die zijn door de overheid verplicht gesteld, vanwege "veiligheid". Echter werken die nog niet zo goed en kunnen rare dingen doen als je op buitenweggetjes rijd of op de snelweg met een weg parallel eraan. Meeste wat ik zie dat men doet is die systemen uitschakelen, want dat is voorspelbaar en veiliger dan lukrake ingrepen op momenten dat je het niet verwacht en het niet nodig is.

Klacht nr2 is de hoge prijs. Wat ook weer komt omdat fabrikanten al die rijhulpsystemen moet implementeren.

Op dat stuk is de overheid dit te vroeg gaan afdwingen en is het idd bizar.

[downtime]

Hebben overheden inmiddels niet bewezen compleet incompetent te zijn m.b.t. techniek en inovatie?

NASA is een deel van de Amerikaanse overheid. Dankzij die overheid hebben we een man op de maan gezet. Noem je dat incompetent? Het internet zelf is een ontwikkeling van DARPA. World wide web is begonnen bij CERN een intergouvernementele organisatie. Kernenergie? Product van een overheid. GPS? Dito.

De overheid is prima in staat om standaarden op te stellen. Want het zijn niet de politici zelf die de standaarden opstellen. Die zetten gewoon capabele mensen aan het werk. Gaat wel eens fout maar gaat ook heel vaak goed.

Dat wil niet zeggen dat de overheid ons moet dwingen om Rust te gebruiken. Rust is gereedschap. De overheid heeft hele boeken aan eisen waaraan woningen moeten voldoen maar die vertellen een timmerman niet wat voor hamer hij moet gebruiken. Hij mag ook met zijn blote handen een spijker inslaan. Dat doet er namelijk niet toe zolang het eindresultaat maar aan de wettelijke eisen voldoet.

[djc]

Het verschil met Java is dat Rust efficiënt genoeg is dat je er software zoals OpenSSL (met een wat matig security track record) kan vervangen door rustls zonder dat je er performance aan verliest.

Java is ook memory safe, maar onderzoek laat zien dat zelfs als je garbage collector redelijk snel is je nog steeds behoorlijk wat extra geheugen nodig hebt (factor 5?).

Dus ja, met Rust kan je je software waar efficiëntie essentieel is herschrijven in een memory safe language, en dat is een grote verbetering als je ziet dat tot 70% van de vulnerabilities komen door memory safety issues.

Full disclosure: ik ben een van de rustls maintainers (AMA).

[martijn600]

Prima reactie, wel opmerking:
Het aangehaalde onderzoek dat Java garbage collection behoorlijk wat extra geheugen nodig heeft, komt uit 2005. Toen was Java 5 de recentste versie.
Sindsdien is in Java veel aan garbage collection en memory management verbeterd.

Natuurlijk wil ik hier geen 'Programming Language war' voeren (overigens programmeer ik niet veel meer in Java), maar in dit geval lijkt me het relevant te vermelden dat het een onderzoek van 20 jaar geleden is.

[badnews.nl]

Een programmeertaal moet juist passen bij je oplossing. Standards zijn voor communicatie.

Waarom zou een taal moeten voldoen aan bv een grafische interface standard als het alleen backend doet, of webinterfaces een standard hebben voor 3d graphics,

Hoe meer programeertalen door bv overheid worden beinvloed, hoe minder innovatie

[jaapzb]

Wat voor standaarden bedoel je dan precies? Een programmeertaal is gewoon een stuk gereedschap. Je hebt verschillende gereedschappen voor verschillende doeleinden, en het verschilt per situatie en per persoon welk gereedschap waarvoor de voorkeur heeft.

Ik zie niet hoe de overheid daarin "standaarden" kan stellen, of waarom je dat uberhaupt zou willen.

[davekok]

Een veiligstandaard bijvoorbeeld. Minimale eisen zodat je buffer overflows en underruns niet meer mogelijk zijn. Of pointer exceptions.

En als je alle nerds op een stokje wilt hebben. Een standaard voor white space. Tabs in plaats van spaties bijvoorbeeld voor indentatie.

[Reactie gewijzigd door davekok op 5 september 2025 13:03]

[downtime]

En als je alle nerds op een stokje wilt hebben. Een standaard voor white space. Tabs in plaats van spaties bijvoorbeeld voor indentatie.

Dat zou onzinnig zijn. In een ontwikkelteam wil je een standaard voor white space hebben om leesbaarheid te verbeteren en dat leidt weer tot efficienter werken en minder fouten. En soms kies je een standaard gewoon om te zorgen dat alle tools ermee werken.

Maar dat zijn allemaal interne voordelen en elk team kan (en moet) zijn eigen afweging maken. Dat zal de overheid allemaal worst zijn want dat heeft geen enkele invloed op het eindproduct.

[davekok]

Oh, geen humor.

[Kun]

In feite is dat wat bijvoorbeeld de NSA heeft gedaan (en andere organen iirc).

https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4223298/nsa-and-cisa-release-csi-highlighting-importance-of-memory-safe-languages-in-so/

Of het in een standard te vangen is vraag ik me af, maar vind het wel een leuk idee.

[Niemand_Anders]

Je moet de RIB meer zien als de tegenhanger van de Mozilla Foundation of hoe de Linux foundation bijvoorbeeld Microsoft's DocumentDB heeft geaccepteerd.

[erik_97]

Voor niet bekent was met Rustls, het is een project van Internet Security Research Group, de organisatie achter Letsencrypt