Beveiligingsexpert werkt fulltime aan Rust-code in Linux dankzij steun Google

Een ontwikkelaar van de Internet Security Research Group gaat een jaar lang fulltime bezig met Rust for Linux dankzij financiële steun van Google. Het project moet betere geheugenbeveiliging bij de Linux-kernel opleveren.

De ontwikkelaar, Miguel Ojeda, werkte bij ISRG al parttime aan het Prossimo-initiatief voor geheugenbeveiliging van de Linux-kernel, maar doet dit dankzij de steun van Google vanaf april fulltime, zo maken Google en ISRG bekend.

Volgens de initiatiefnemers van het Prossimo-project, heeft Linux te maken met geheugenkwetsbaarheden omdat de kernel in C geschreven is. Ze denken de problemen in de toekomst te kunnen voorkomen door het mogelijk te maken Linux-kernelmodules in Rust te ontwikkelen. Daarvoor haken ze aan bij het Rust for Linux-project.

Ojeda erkent dat het toevoegen van een tweede taal aan de Linux-kernel een beslissing is die zorgvuldig gewogen dient te worden, maar volgens hem brengt Rust voldoende voordelen boven C om dit te doen. Hij publiceerde eerder een RFC voor de implementatie. Linus Torvalds toonde interesse in het project, maar verklaarde tegen ZDNet dat het voornamelijk gedreven leek uit enthousiasme voor Rust, en dat het wachten was op concrete resultaten.

Rust is een door Mozilla ondersteunde programmeertaal die gericht is op prestaties, beveiliging, betrouwbaarheid en productiviteit en die onder andere door Google, Discord en Microsoft ingezet wordt. De Internet Security Research Group is ook de organisatie achter de ssl-certificaten van Let's Encrypt.

Reacties (95)

[Barsonax]

Mooie taal, zal zeker nog wel verder groeien qua populariteit.

Compile time geheugen bugs eruit halen is gewoon een enorm groot voordeel ten opzichte van C/C++.

Maar verder biedt de taal ook wel mooie features zoals traits en discriminated unions aan.

[witchdoc]

Kan iemand een totale programming noob uitlleggen waarom rust zoveel beter zou zijn dan C sp[ecifiek voor geheugen shizzle?

[Riddled]

C werkt veel met pointers. Die verwijzen naar een plaats in het geheugen waar data staat (in plaats van zelf de data te bevatten). Voordeel is dat als je op meerdere plaatsen in een programma dezelfde pointer hebt, ze allemaal hetzelfde stukje geheugen uitlezen. Je moet dus geen kopieën maken van data, en die kopieën niet in sync houden met elkaar.

Als je klaar bent met je data, dan doe je een 'free' call om dat geheugen weer vrij te geven. Daaruit kunnen echter wat problemen komen als je op meerdere plaatsen een pointer naar die data hebt staan... na de free zijn deze allemaal ongeldig (dangling pointers) en zouden niet meer gebruikt mogen worden.

Sommige talen maken die oude pointers ongeldig (wat redelijk kostelijk is qua execution time), maar in C blijven die gewoon werken ook al verwijzen naar geheugen dat mogelijk voor iets anders gebruikt wordt. Als die pointers dan nog gebruikt worden, krijg je 'use after free' bugs. Dit kan o.a. gevaarlijk zijn als een aanvaller er in slaagt om zelf iets in het geheugen te zetten op die plaats om zo het programma over te nemen. Of je kan per ongeluk 2x een free doen op dezelfde pointer en zo andere pointers om zeep helpen.

Rust heeft een paar speciale regels rondom het gebruik van pointers. Dat is wat lastiger programmeren en moet je aan wennen. Tijdens het compilen van de code gaat Rust nagaan of die regels worden nageleeft. Indien dat zo is, kan Rust garanderen dat je geen use after free/double free meer hebt. Je hebt dus memory safety, zonder tijdens runtime altijd te moeten nagaan of er nog andere pointers zijn die ongeldig gemaakt moeten worden telkens er wat geheugen wordt vrijgegeven.

[uiltje]

"Daar moet je aan wennen" is wel een understatement waar het gaat om pointers / references. Het hele idee van ownership is nou net wat bij talen als Java geen probleem meer is. Bij Rust kan je de ownership overdragen. Fijn, maar het lost het probleem niet echt op naar mijn mening.

Een simpel iets als reference counting is wel mooier en heeft het voordeel dat je code kan aanroepen meteen als het object niet meer beschikbaar is. Maar dat gaat wel ten koste van snelheid; Java is bijvoorbeeld sneller met de garbage collect.

[Jeanpaul145]

Fijn, maar het lost het probleem niet echt op naar mijn mening.

Want? Ik werk al 6 jaar probleemloos met Rust, dus hier ben ik wel nieuwsgierig naar.

Een simpel iets als reference counting is wel mooier en heeft het voordeel dat je code kan aanroepen meteen als het object niet meer beschikbaar is. Maar dat gaat wel ten koste van snelheid; Java is bijvoorbeeld sneller met de garbage collect.

Zowel refcounting als GC hebben runtime overhead costs, refcounting vooral door de noodzaak van atomic refcount updates (en dus is de overhead voornamelijk in termen van runtime), en GC in zowel RAM (4-6x(!) memory overhead tov een vergelijkbaar native proces) als tijd (stop-the-world pauzes, mark-and-sweep, etc).

Dit is het probleem dat opgelost wordt met ownership, management is nl gratis op runtime door de analyse naar compile time te verschuiven.

[latka]

GC in 2021 is niet meer de GC uit 2000. Stop-the-world en mark&sweep zijn iig. in Javaland verleden tijd (ZGC). Ook refcounting is niet meer iedere update automatisch het (atomisch) bijwerken van velden. Ik zeg niet dat het probleem op een aardige mannier ook tacklet. Alleen de argumenten waarom zijn niet meer van deze tijd. De memory overhead (4-6x?) herken ik al helemaal niet. Maar dingen in compiletime oplossen ipv. in runtime is altijd beter (daar kan Javascript nog heel wat van leren).

[Xander2]

Dat niet alleen, in sommige gevallen is een GC sneller (b.v. heel veelvuldig (de)addresseren in een compiler) dan manueel.

[Barsonax]

Java, C# en andere talen met een garbage collector hebben een heel ander doel dan Rust. Het moet vooral 'makkelijk' zijn en dat is precies wat er gebeurt in die talen. Daar hoef je je helemaal niet bezig te houden met pointers.

Echter dat heeft wel een performance impact en die impact is ook nog eens niet gelijkmatig verdeeld. Bij Rust wordt alles compile time al gechecked en krijg je dus betere performance en ook betere voorspelbaarheid. Daarnaast is je binary lekker klein want je hebt geen runtime nodig.

Al die talen zijn uiteindelijk general purpose talen maar met deze sterke ounten zal je Rust voornamelijk op lagere lagen tegen gaan komen waar normaliter C/C++ veel wordt gebruikt.

[Killemov]

Java, C# en andere talen met een garbage collector hebben een heel ander doel dan Rust. Het moet vooral 'makkelijk' zijn en dat is precies wat er gebeurt in die talen. Daar hoef je je helemaal niet bezig te houden met pointers.

Het doel is om het de ontwikkelaar makkelijker te maken en dat is maar ten dele gelukt. Je hoeft niet meer expliciet blokken geheugen te reserveren of vrij te geven. Het kan zo maar gebeuren dat een niet meer relevante referentie blijft bestaan. En als dat ook nog eens op een niet kritieke plek zit, dan kun je zomaar maandelijks uit je geheugen lopen. Dat geldt voor alle resources, je moet ze weer bewust vrijgeven. De Java "AutoClosable" interface is met terugwerkende kracht op veel bestaande classes toegepast om de pijn wat te verlichten, maar verdient ook niet echt de schoonheidsprijs.

Ik betwijfel of Rust wat dat betreft resource-safe is geworden.

[diondokter]

Het is mogelijk om een RC loop te creëren die dan vervolgens leakt. Maar ik ben dat ben ik na 2 jaar Rust programmeren nog niet tegen gekomen.
Verder dan dat, tenzij je expliciet leakt (soms kun je dat willen), worden alle resources netjes opgeruimd.

[Barsonax]

Ervoor zorgen dat je pointers veilig gebruikt is wel een heel ander probleem dan ervoor zorgen dat je references in C#/java etc tijdig worden opgeruimd zodat je niet onnodig geheugen vasthoudt. Dat laatste is veel makkelijker. In die zin maakt de garbage collector het wel een stuk makkelijker voor je.

Neemt natuurlijk niet weg dat zeker voor de wat meer ervaren dev het toch echt noodzakelijk is dat je enige kennis hebt over wat er onder de motorkap gebeurt. Zeker als ook performance een rol gaat spelen moet je wel.

[Sp3ci3s8472]

Om te zeggen dat je geen ownership hebt in talen zoals C# en Java vind ik wel ver gaan. Dit heb je nog steeds en je moet nog steeds zorgen dat je data netjes neerzet zodat de GC het ook daadwerkelijk kan opruimen.

[Killemov]

Yup. Dat geldt voor alle resources, niet alleen geheugen.

[diondokter]

Maar hoezo lost dat het probleem niet op denk je?

Als je ownership moet overdragen, dan kan de eigenaar het object opruimen wanneer die out of scope gaat. Hierdoor heb je geen GC meer nodig, wat goed is voor de performance en de runtime size. Hierdoor is Rust geschikt om te gebruiken op alle plekken waar C en C++ ook voor komen (OS, DB, Embedded, etc.).
Maar doordat het erg goede high-level concepten ook ondersteund (veelal geleend van bijv. Haskell), is het ook competatief op plekken waar traditioneel andere talen gebruikt voor worden zoals Java/C#/Python/JS. Dit wil je niet doen met C, omdat het veel abstractie capabilities mist.

[biteMark]

Ik vraag me af of gc de reden is dat java sneller is, dat ligt misschien aan de implementatie van arc waar je het mee vergelijkt (ObjC toevallig? ) Conceptueel vind ik arc inderdaad een mooiere oplossing en voor user space code waar snelheid niet cruciaal is zijn zowel gc als arc gewoon goede oplossingen en waarschijnlijk merkt de gebruiker nooit het verschil tussen beide.

Heb je het echter over kernel space code, dan zijn o.a. snelheid en resource impact altijd cruciaal, gc en arc zijn dan totaal ongeschikt vanwege de overhead en is de oplossing van Rust imho waarschijnlijk de beste die nu beschikbaar is en redelijk breed gedragen wordt.

[Jeanpaul145]

In C en Rust heb je 2 soorten geheugen: de stack en de heap.
Management van de stack is snel, en de stack wordt oa gebruikt om functies te callen en kleinere stukjes data op te slaan. Ook is het zo dat stukjes informatie die 100% op de stack leven, vanzelf worden opgeruimd zonder dat je daar als programmeur iets voor hoeft te doen. Het ding is alleen, de stack is nogal beperkt in omvang (doorgaans niet meer dan 8MB per proces, en vaak zelfs maar ½-1MB, bijvoorbeeld WASM modules in de meeste WASM engines) en is dus ongeschikt voor de opslag van grotere stukken data, of van grote collecties van kleine stukken data, of van arbitrair lange collecties van data.

Dus grotere stukken data worden daarom doorgaans op de heap gegooid. Dit wordt in de kern handmatig gedaan in C met malloc() (om geheugen te alloceren maw toe te wijzen) en free() (om gealloceerd geheugen weer vrij te geven).

Het probleem is, handmatig je heap moeten managen is enorm foutgevoelig, en er worden dan ook heel veel fouten in gemaakt, zelfs door mensen die doorgaans weten wat ze doen.
Rust helpt hier door het managen van de heap een stuk makkelijker te maken adhv het ownership- en borrowingsysteem. Dat is een compile time analyse die zorgt dat wanneer de eigenaar van een stuk data niet langer nuttig is, zowel eigenaar als de data zelf automatisch worden vrijgegeven.
Het is in de praktijk soms complexer dan dat, maar dat is het basisidee en zo werkt 't voor heel veel types (maar niet voor allemaal).
Dus in die zin levert de borrow analyse dezelfde voordelen als een garbage collector, alleen dan zonder de (heel significante, in zowel tijd als in RAM) runtime overhead die dat met zich meebrengt (dat is waarom een taal met een GC automatisch ongeschikt is om bv een kernel mee te ontwikkelen. Je kan t technisch gesproken doen maar de performance wordt om te janken).

Laat het nou net zo zijn dat research van oa Microsoft aan heeft getoond dat in grotere C/C++ code bases grofweg 70% van alle security vulnerabilities worden veroorzaakt door zulke memory management issues, en je ziet al snel waarom Rust hier zo enorm bij helpt.

[Reactie gewijzigd door Jeanpaul145 op 22 juli 2024 23:55]

[Cilph]

Rust houdt onder andere ownership bij van alle data/pointers, wat compile-time verifieerbaar moet zijn. Hierdoor is er de garantie dat een grote groep een fouten niet kunnen voorkomen.

[Sissors]

Het verbaasd mij dan weer wel dat bij gebruik van de taal, het de standaard is om niet expliciet type van variabele te declareren, en ook bijvoorbeeld returns worden impliciet gedaan. Dat soort dingen gewoon expliciet opschrijven lijkt mij positief voor de veiligheid. En makkelijker leesbaar voor mij

[84hannes]

ook bijvoorbeeld returns worden impliciet gedaan

Dat is niet waar.

{
let a = 5;
a;
}

geeft niets )of eigenlijk, een lege tuple, '()') terug, terwijl

{
let a = 5;
a
}

dus zonder puntkomma, hetzelfde betekent als

{
let a = 5;
return a;
}

Het lijkt misschien een subtiel verschil, maar de signature van de functie geeft al aan dat de functie iets terug moet geven, dus het vergeten van een puntkomma levert vanzelf een foutmelding op. Ook een vergeten puntkomma halverwege geeft een foutmelding

{
let a = 5;
a
let b = 6;
b
}

omdat

a let b = 6;

geen valide syntax is. Je zult in dit geval expliciet 'return' moeten gebruiken en dat zal je weer een waarschuwing opleveren omdat de regel er onder onbreirkbaar is. Je kunt deze voorbeelden rustig uitproberen in de Rust Playground.

[Reactie gewijzigd door 84hannes op 22 juli 2024 23:55]

[Jeanpaul145]

Voor de veiligheid maakt 't geen drol uit. Wanneer je het type van een local binding weglaat (de enige plek waar je types mag weglaten op die manier) wordt dat type automatisch berekend (inferred) door de type checker. De code betekent dus 100% exact hetzelfde, ongeacht of je 't type handmatig opschrijft of niet.

VWB wat makkelijk leesbaar is, dat is een kwestie van voorkeur.
Wel is het zo dat er anonieme types bestaan, maw types die helemaal geen naam hebben (bv elke closure heeft een uniek type die een van de traits Fn, FnMut en FnOnce implementeert) en daar kan het dus niet anders dan dat je 't type weglaat.

Dus ongeacht wat je van het weglaten van types an sich vindt, het is een feature die niet eens weggelaten had kunnen worden uit de taal.

[Reactie gewijzigd door Jeanpaul145 op 22 juli 2024 23:55]

[Sissors]

Voor de veiligheid maakt 't geen drol uit. Wanneer je het type van een local binding weglaat (de enige plek waar je types mag weglaten op die manier) wordt dat type automatisch berekend (inferred) door de type checker. De code betekent dus 100% exact hetzelfde, ongeacht of je 't type handmatig opschrijft of niet.

Als jij expliciet opschrijft dat iets integer, is dan krijg je een foutmelding als het geen integer is. Bij inferred typische gaat hij gewoon lekker door en denk je met een integer bezig te zijn, terwijl het iets heel anders is. En natuurlijk, vaak genoeg zal je dan later alsnog een foutmelding krijgen, maar dat is niet zeker.

[Jeanpaul145]

En natuurlijk, vaak genoeg zal je dan later alsnog een foutmelding krijgen

Dan denk ik dat je een beetje een vertekend beeld hebt van hoe Rust werkt. Om te beginnen heb je in een gegeven fn F input parameters, en die hebben altijd expliciet een type.
Vanaf daar kan je local bindings maken bv met het callen van een andere fn G, en ongeacht of je daar een type opgeeft of niet krijg je daar het type uit dat G aangeeft in z'n signature.

Nou stel je hebt je binding B en je zet daar geen expliciet type neer. Als dat niet het type is dat je zou verwachten, krijg je een foutmelding bij de eerste operatie die je probeert te doen op B. Dat is vaak maar 1 of een paar regels lager. Maw je ziet 't meteen.

[Reactie gewijzigd door Jeanpaul145 op 22 juli 2024 23:55]

[jj71]

Bij inferred typische gaat hij gewoon lekker door en denk je met een integer bezig te zijn, terwijl het iets heel anders is.

Nee, zo werkt dat niet. Type inference betekent niet dat er ook meteen sprake is van dynamic typing.

Er zijn grofweg twee soorten programmeertalen: talen met static typing en talen met dynamic typing.

C, C++, C#, Java en Rust zijn allemaal statically typed. Dat betekent dat de types van variabelen tijdens compile time al vaststaan. Sommige van die talen hebben ook type inference, wat betekent dat je de types van variabelen niet (altijd) expliciet hoeft te noemen in de source code. De compiler kan in dat geval uit de context afleiden wat het type is.

JavaScript en andere meer script-achtige talen zijn dynamically typed. Dat betekent dat het type van een variabele niet vaststaat tijdens compile time. Terwijl het programma draait kan ook het type van de variabele veranderen, als je er een waarde van een ander type aan toekent.

Je hebt het over type inference, maar je uitleg slaat op wat er in een dynamically typed taal gebeurt. Dat zijn dus twee heel verschillende dingen.

Rust is dus statically typed, maar heeft wel type inference. Als je een variabele hebt waarvan het de bedoeling was dat het een int was, maar je hebt er iets anders aan toegekend, dan heeft de variabele het type van dat wat je eraan had toegekend. En als dat verkeerd is zul je het al heel snel tijdens compile time merken omdat je een compile error krijgt, en niet pas tijdens runtime (zoals in een dynamically typed taal).

[Sissors]

Dat is toch ook exact wat ik schreef? Bij inference gaat de compiler gewoon lekker door met wat jij denkt dat een integer was, als ander type te behandelen. Of dat statisch of dynamisch is veranderd dat niet. Terwijl als hij als integer was gedefinieerd, je een error krijgt dat je iets in een integer probeerd te stoppen wat geen integer is.

Je zal alleen een compile error krijgen, als je later dingen doet die je niet met het onverwachte type mag doen. En zoals ik al eerder schreef, vaak zal dat gebeuren, maar dat is niet zeker. Als je alleen zaken met die variabele doet die je zowel met een integer als dit andere type mag doen, dan vindt de compiler alles prima.

(En wat dus ook zal komen door wat ik gewend ben, maar ik vind het gewoon handig om direct te kunnen zien of iets een integer, float, int8, of een heel ander type is).

[Jeanpaul145]

Bij inference gaat de compiler gewoon lekker door met wat jij denkt dat een integer was, als ander type te behandelen.

Nee dus. In een "dynamically typed"¹ taal zou dat idd vrolijk doordraaien op runtime. Maar in Rust draait de code helemaal niet, want daarvoor moet 't eerst compileren, en dat is exact wat de compiler dan niet wil doen gegeven dat de types niet kloppen.

¹"Dynamically typed" is een contradictio in terminis, gegeven dat type systems per definitie op compile time werken. De tagged values die bv Python gebruikt zorgen dat je op runtime lookups kan doen voor bv method calls, maar dat maakt 't geen type systeem.

[Reactie gewijzigd door Jeanpaul145 op 22 juli 2024 23:55]

[Sissors]

Of ik begrijp het echt niet, of ik maak mijn punt niet duidelijk.

Het gaat niet over runtime, het gaat over compile time. Ik begrijp niet echt waarom steeds runtime erbij wordt gehaald, gezien ik zelf nooit runtime hebt genoemd. Ik heb altijd compile time bedoelt. Echter je gaat ervan uit dat de compiler 100% zeker een error zal geven. Oftewel dat het onmogelijk is een stuk code te hebben wat te compileren is met twee verschillende soorten variabelen. En dat geloof ik niet.

[Jeanpaul145]

Onmogelijk is 't technisch gesproken niet, maar wel extreem onwaarschijnlijk. Dat zeg ik gebaseerd op 6 jaar ervaring met Rust en in die tijd heb ik 't nog niet eens 1 keer meegenaakt. Daarnaast baseer ik dat op het feit dat ik anderen nog nooit heb horen praten of klagen of zo'n issue. Dus in de praktijk is de kans zo bijzonder klein dat het niet de moeite waard is om erop te letten.

Want voor zoiets om voor te moeten komen, moet je 2 types hebben die beide gereturned kunnen worden door 1 of andere operatie, en daar gaat het al fout eigenlijk. Per definite geeft een expressie maar 1 value terug met 1 type. Je kan een `impl Trait` value returnen in fns maar ook dat zijn types, alleen anonieme types.

En alsof dat niet genoeg was, als je een editor of IDE gebruikt met rust-analyzer kan je gewoon naar het type van een binding kijken door erop te hoveren met je cursor. Dit reduceert de <1% kans dat zoiets gebeurt naar exact 0.

[Reactie gewijzigd door Jeanpaul145 op 22 juli 2024 23:55]

[Zoijar]

Onmogelijk is 't technisch gesproken niet, maar wel extreem onwaarschijnlijk. Dat zeg ik gebaseerd op 6 jaar ervaring met Rust en in die tijd heb ik 't nog niet eens 1 keer meegenaakt. Daarnaast baseer ik dat op het feit dat ik anderen nog nooit heb horen praten of klagen of zo'n issue. Dus in de praktijk is de kans zo bijzonder klein dat het niet de moeite waard is om erop te letten.

Ik heb de laatste 10 jaar C++ ook nog nooit een memory leak of pointer error meegemaakt

Wel heb ik best vaak type errors meegemaakt, waar je bijvoorbeeld iets serialized naar een database en dan een double stuurt ipv een int.

[Reactie gewijzigd door Zoijar op 22 juli 2024 23:55]

[Jeanpaul145]

Ik heb de laatste 10 jaar C++ ook nog nooit een memory leak of pointer error meegemaakt

Niet dat je weet in elk geval 😉

Wel heb ik best vaak type errors meegemaakt, waar je bijvoorbeeld iets serialized naar een database en dan een double stuurt ipv een int.

Dat is het domein van ORM, en totdat ik met diesel ging werken zou ik niet gedacht hebben dat het ORM probleem wat dat soort type mappings betreft behoorlijk opgelost kan worden.
Maar wat blijkt, met een beter type systeem dan iets als Java tot z'n beschikking heedt, en geen inheritance in de taal, worst het probleem een stuk behapbaarder¹.
Ik gebruik Diesel dan ook naar volle tevredenheid.

¹Er zullen vast meer factoren zijn dan alleen die 2.

[Melleth]

Je kan best het type er bij zetten als je dat graag wilt. Voor zover ik weet slaat de compiler je niet perse met een warning als je dat doet, misschien de linter clippy, maar dat weet ik ook niet zeker. Anyway, je kan ook als je zeker wilt zijn van een f32 de subfix annotatie achter een getal expressie gebruiken. Hij introduceert een cast als je bijvoorbeeld let a = 1f32; schrijft, terwijl let a: f32 = 1; niet werkt.

https://play.rust-lang.or...2a3fcaab367eb4247203d2579

[gimbal]

Of je het nou expliciet zelf moet opschrijven of dat het afgeleid kan worden van de declaratie dat maakt voor het eindresultaat niet uit, het is en blijft een harde typering.

Maar het zelf opschrijven is in mijn mening toch een tikkie beter voor de zelf-documentatie van code.

[diondokter]

Dat dingen impliciet gebeuren, betekent dat niet dat het niet gecheckt wordt!
Alles is strongly statically typed en als het uit de context niet duidelijk wordt welke type je ongespecificeerde variabele is, dan is dat een compiler error.

[Barsonax]

Ik heb wel eens code bases gezien waar men overal een type bij zet en dat is best wel erg verbose.

Heel vaak is het type al overduidelijk als je de source leest. In die gevallen is het prima om dat type impliciet te laten zijn.

Op die plaatsen waar het de code duidelijker maakt kan je altijd het type er altijd nog bij zetten:

let a: u32 = 5;

Als je dat heel vaak nodig gaat hebben omdat anders je code niet goed leesbaar is dan klopt er wellicht iets anders niet meer in je code (te lange functies wellicht?).

Overigens is alles statically typed in Rust wat wil zeggen dat alle types compile type bekend zijn. Uiteindelijk in de machine code komt dit dus op hetzelfde neer, er komen niet ineens dynamische checks bij omdat jij niet zelf expliciet een type in je source code hebt staan.

[Reactie gewijzigd door Barsonax op 22 juli 2024 23:55]

[Killemov]

Bedoel je dan de Hongaarse notatie voor variabelen?

[theborgnl]

En hier dacht ik dat het ging om een port van de game Rust naar Linux... ik vroeg me al af waarom Google dat steunde.

Anyway, ik kende Rust niet (doe eigenlijk alleen Java en Python)... maar die memory safe dingen klinkt wel handig voor een beperkte programmeur als ik.

[laurxp]

Qua memory safety is Rust niet beter dan Java of Python. Het grootste gewin is dat ze het voor elkaar hebben gekregen om deze safety te hebben zónder garbage collector.

Rust is én veilig én retesnel, in plaats van of-of.

[The Zep Man]

Anyway, ik kende Rust niet (doe eigenlijk alleen Java en Python)... maar die memory safe dingen klinkt wel handig voor een beperkte programmeur als ik.

Een voorbeeld is vaultwarden (voormalig bitwarden_rs), een open source password management server geschreven in Rust. Je hoeft Rust uiteraard niet te kennen om het te implementeren.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 23:55]

[sympa]

Firefox is ook een gebruiker van Rust. Het komt zelfs bij Mozilla vandaan.

[diondokter]

Je komt voor de memory safety, maar je blijft door de super tools, geweldige error messages en ook gewoon omdat het een super fijne taal is om mee te werken.

[vanwijnen]

Een voorbeeld waar ik aan meewerk is One Tagger.
Back-end volledig in Rust. Front-end in Vue.js
Cross-platform, open source, gratis.

[justinkb]

De rust compiler lijkt me nog niet echt volwassen genoeg voor zulke kritieke software. In rust zit al sinds de allereerste versie een grote bug die voor verborgen miscompilaties kan zorgen. Deze bug is in de laatste release nog niet opgelost, maar er wordt sinds 1.52.1 omheen gewerkt. Mijns inziens nog geen goed idee dit

[bzzzt]

Sinds 1.24 is er de mogelijkheid 'incrementeel' te compileren (dwz: niet alle source code iedere keer opnieuw compileren bij een kleine wijziging). Dat lijkt tot bugs te leiden en is in 1.52.1 uitgeschakeld.
Ik kan geen specifieke gevallen vinden waarin dit optreedt, maar als het al zoveel versies meegaat is het waarschijnlijk een vrij zeldzaam geval.
Misschien is het een beetje vreemd als je 'weet hoe de worst gemaakt wordt', maar iedere compiler (ook ultra-stabiele productie versies) bevat bugs. Dat zegt niet dat de overige verbeteringen niet ruim opwegen tegen de voordelen van rust.

[justinkb]

De "established" C/C++ compilers, gcc en clang, hebben natuurlijk zeer uitgebreide regressietests die in de loop van decennia zijn opgebouwd, dus een bug in iets wat in een vorige versie wel werkte sluipt daar niet zomaar in een release.

[bzzzt]

Ja, laten we vooral eerst 40 jaar test cases schrijven voordat we iets in productie nemen wat de kans op geheugen bugs en exploits vermindert...
Hoewel ik compiler bugs echt wel serieus neem worden de meeste zwakheden toch echt door applicatieprogrammeurs veroorzaakt. Ik zou op dit moment geen moment twijfelen tussen C/C++ en Rust voor een project zonder heel specifieke hardware of integratie eisen.

[gimbal]

Eraan werken om het mogelijk te maken is niet hetzelfde als dat het per direct mogelijk is. Er kan nog rustig een jaar of twee overheen gaan voordat het zover is en tegen die tijd kan Rust zelf al vele malen stabieler zijn.

[Jeanpaul145]

Welke bug is dit? Mag ik hier wat meer informatie over?

[justinkb]

https://blog.rust-lang.org/2021/05/10/Rust-1.52.1.html gaat er uitgebreid over

[Jeanpaul145]

Ah dank je wel.

In de release notes staat dat incremental compilation standaard uit staat bij release builds, dus ik denk dat het in de praktijk mss wat irritatie veroorzaakt bij sommige rust ontwikkelaars (zelf in elk geval nooit last van gehad, en ik zit altijd op de meeste recente stable rustc) maar ik denk ook dat de impact in de praktijk best zal meevallen.

[Xieoxer]

Rust is inmiddels de hippe taal binnen de wereld van C en C++. Rust heeft veel voordelen als het gaat om memory beheer tegenover C en C++. Maar als je complete controle wilt hebben en optimale prestaties wilt hebben dan kun je beter zelf de memory gedeelte zelf afhandelen. Alleen dan bestaat het gevaar dat er security issues kan creëren als je de code verkeerd begrijpt of op de verkeerde manier toepast. Er zijn steeds minder goede C en C++ programmeurs te vinden, waardoor je wilt groei krijgt van allerlei soorten code / implementatie. Tevens zijn er verschillende versies geweest binnen C++, waarin sommige acties veel beter zijn geworden. Zeker de laatste versies heeft veel overeenkomsten met Rust, maar op internet vindt je vooral veel “oude” voorbeelden. Rust lost bovenstaande problemen dus op, en maakt het makkelijker om als nieuwe ontwikkelaar in te stappen in een bestaand project. Ik verwacht dat veel bestaande applicaties zoals VLC / FFmpeg zullen niet snel afstappen van C, omdat deze projecten te groot zijn om even om te bouwen. Ze hebben nu al te weinig “man” kracht om hun nieuwe features etc te bouwen. Ik verwacht we dat nieuwe applicaties direct gebruik gaan maken Rust.

[Reactie gewijzigd door Xieoxer op 22 juli 2024 23:55]

[TheVivaldi]

VLC is al deels afgestapt van C want op Linux wordt het Qt-frontend gebruikt. En laat Qt nu net gebaseerd zijn op C++

[Xieoxer]

Qt is een toolkit, geen aparte taal. Qt toolkit maakt het mogelijk om interfaces te bouwen voor meerdere platformen. Qt is geschreven in de taal C++. Volgens de GitHub bestaat VLC grotendeels nog steeds uit C: https://github.com/videolan/vlc

Volgens de Wikipedia: Qt is a widget toolkit for creating graphical user interfaces as well as cross-platform applications that run on various software and hardware platforms such as Linux, Windows, macOS, Android or embedded systems with little or no change in the underlying codebase while still being a native application with native capabilities and speed.

[Reactie gewijzigd door Xieoxer op 22 juli 2024 23:55]

[Jeanpaul145]

Dat VLC grotendeels gebaseerd is op C is logisch. Om te zien waarom, bedenk dat VLC:
- Multiplatform is en dus portable moet zijn
- Al best oud is als project (eerste release is van 2001) en dus iets als Rust nooit een optie geweest was
- Heel veel low level bit twiddling moet doen ivm de/coden van media files, dus GC languages zouden 't sowieso niet worden, al helemaal met de garbage collector performance van toen

C++ kan een hoop, maar ik zou (ook toen) nooit de core van een project dat portable had moeten zijn in C++ geschreven hebben, gewoon voor mijn eigen mentale gezondheid. Aan de andere kant is Qt wel een van de beste GUI kits die er waren (al helemaal toen), en dus is 't goed te rechtvaardigen om de GUI dan daarmee te bouwen; te meer omdat C++ moeiteloos C can callen (de omgekeerde richting op is nog lang zo makkelijk nog niet).

[bzzzt]

Vergeet niet dat VLC eigenlijk voornamelijk gebruik maakt van third-party implementaties van video codecs en die vrijwel allemaal gebouwd zijn in C. De bulk van de logica zal daarin zitten, niet in de GUI. Het eventueel herbouwen van die code in een andere taal zal opgepakt moeten worden door hun 'upstream'.

[Jeanpaul145]

bulk van de logica zal daarin zitten,

Zoals erkend in punt 3 van mijn lijstje 😉

[84hannes]

C++ kan een hoop, maar ik zou (ook toen) nooit de core van een project dat portable had moeten zijn in C++ geschreven hebben,

Als je VLC werkend wilt krijgen op een 8051 dan zou C++ inderdaad een beperking kunnen zijn. Maar VLC is toch al lastig omdat het op bepaalde stukken hard- en software moet vertrouwen, zoals codecs en schermen. Ik weet niet of VLC ook zonder GUI te compileren is, maar als de GUI beperkt wordt door C++/Qt dan zie ik geen probleem de rest van de code daar ook toe te beperken.
Daarbij heeft Rust prima compatibility met C, vandaar ook dat het relatief eenvoudig in de Linux kernel gebruikt kan worden. Nieuwe code voor VLC zou dus zonder al teveel moeite in Rust geschreven kunnen worden, mits je accepteert dat dat je tool chain uitbreid.

[Jeanpaul145]

Mijn uitleg is vanuit historisch perspectief, specifiek vanaf het moment dat ze begonnen met developen (wss 1999 of 2000).

Daarbij heeft Rust prima compatibility met C, vandaar ook dat het relatief eenvoudig in de Linux kernel gebruikt kan worden. Nieuwe code voor VLC zou dus zonder al teveel moeite in Rust geschreven kunnen worden, mits je accepteert dat dat je tool chain uitbreid.

Dus dit is leuk een aardig, maar ik verwacht niet dat ze dat gaan doen. De reden is een simpele kosten/baten analyse: als ze Rust in de mix gooien hebben ze nu 3 talen intern in het project, wat het build proces enorm irritant en complex maakt. Daarnaast, er is op dit moment geen goede, stabiele GUI toolkit die natively in Rust geschreven is. Met andere woorden, er zal geen GUI geschreven kunnen worden door Rust te adopteren.
Wat blijft er dan over? Codecs. Maar zoals boven aangegeven maakt VLC gebruik van veel 3rd party code, en dat gaan ze dus sowieso niet herschrijven (als ze dat werk wilden hadden ze wel zelf al die codecs geschreven destijds).
Wat blijft er daarna over? Niet zo veel, en daarmee is 't in elk geval in 2021 niet de moeite waard voor het VLC project.

[Reactie gewijzigd door Jeanpaul145 op 22 juli 2024 23:55]

[84hannes]

Ik ben het eens met je analyze. De afwezigheid van stabiele GUI toolkit voor Rust is waarschijnlijk het grootste gebrek, nog buiten het feit dat VLC zijn hele GUI dan zou moeten herschrijven.

[84hannes]

Qt is een toolkit, geen aparte taal.

Dat is grotendeels waar, maar

Qt uses a meta-object compiler, that generates C++ code

Het heeft dus een extra compiler nodig vergeleken met C++, dus ik zou het bijna een taal (bijna maar net niet helemaal strict superset van C++) willen noemen die naar C++ compileert.

[cricque]

Das mooi uiteraard, zo zijn er nog tal van voorbeelden. Maar uiteindelijk heeft Google er ook baat bij, dus het is zeker geen "sponsoring" omdat het leuk oogt. Ze gaan er ook de vruchten van plukken.

[Omega]

Iedereen zal er vruchten van plukken, dat is het voordeel van vrije software. Je zegt het alsof Google kwaadaardig bezig is en dit alleen maar doet voor zichzelf, veel meer mensen en organisaties hebben belang bij dit project dan alleen Google.

Rust in de kernel zal het leven van zij die kernel driver schijven veel makkelijker maken, de software is makkelijker te schijven omdat Rust abstracter is dan C, en de Rust compiler die regelt het geheugenbeheer voor jou.

Het geheugenbeheer is waar verreweg de meeste bugs en exploits vandaan komen, Rust moet dit oplossen.

Het enige grote nadeel van Rust is dat het aanzienlijk langer duurt om te compileren dan C.

[Iblies]

Het is peanuts voor Google.

De vraag die gesteld moet worden is waarom Linux er zelf op dit moment er minder waarde aandacht aan hecht,
en dat google het marketing technisch dusdanig belangrijk vind dat je het ineens overal ziet terugkomen in zelfs mindere blaadjes.


Het is te strak georchestreerd dat je het als liefdadig kunt wegzetten, integendeel. Google is groot geworden op basis van de open community maar het is niet echt wederzijds.

[AmigaWolf]

Tweakers: Een ontwikkelaar van de Internet Security Research Group gaat een jaar lang fulltime bezig met Rust for Linux dankzij financiële steun van Google. Het project moet betere geheugenbeveiliging bij de Linux-kernel opleveren.

Haha, ja natuurlijk, en wat wil Google er voor terug, want Google doet NIKS uit de goedheid van hun hart.

Als ik Google samen met Security zie moet ik altijd hard lachen, heb door dit geen vertrouwen in Internet Security Research Group.

[84hannes]

Als ik Google samen met Security zie moet ik altijd hard lachen

Jij bent in de war met privacy. Google heeft alle belang bij de security van Linux; enig idee wat ransomeware bij Google zou kunnen kosten?

[Reactie gewijzigd door 84hannes op 22 juli 2024 23:55]

[Iblies]

Jij valt dus precies in die val.

Linux is open-source.
Er wordt verwacht dat ELKE gebruiker een steentje bijdraagt, al was het in de vorm van feedback.

Dat betekent dat talloze overheden, financiële instellingen, supermarkt-ketens, transport ketens weten wat er gebeurt op hun netwerken indien ze gebruik maken linux of andere vorm van -nix.

Google wekt nou de illusie dat ze dat nou regelen met clubjes als

Internet Security Research Group

wat complete onzin is. Google heeft niks te zeggennoger internet, het is een verzameling protocollen.


Overigens is het sws triest gesteld met veel bedrijven kwa kennis. Jarenlang is er uitbesteed om te versimpelen, alleen is ict een dusdanig essentieel bedrijfsonderdeel geworden dat je dat niet zomaar kunt verantwoorden.

[84hannes]

Er wordt verwacht dat ELKE gebruiker een steentje bijdraagt,

Ik moet eerlijk bekennen dat ik dat deel van de GPL licentie altijd over sla.

[delphium]

Toch is het niet allemaal rozengeur en maneschijn met Rust. Hier wat perikelen rond de rusificatie van libsvg op Debian:

https://lwn.net/Articles/771355/

Rust is cool, maar voordat het net zo breed wordt ondersteund als C en C++ gaan er nog wel wat jaren overheen. Veel distros ondersteunen een heel scala aan platforms en voor zover ik weet is Rust alleen voor x86_64, i686 en ARM beschikbaar.

Voor je het weet lijdt dit weer tot een scheuring in de community met een Rust-kamp en een C-kamp.

[Jeanpaul145]

Voor je het weet lijdt dit weer tot een scheuring in de community met een Rust-kamp en een C-kamp.

Vroeger dacht ik ook zo. Maar op een gegeven moment realiseerde ik me: dat is een normaal onderdeel van technologische ontwikkeling.. Een tech community splitst zich omdat een deel 1 ding wil en een ander deel iets anders wil dat niet compatibel is met wat de eerste groep wil. En vaak komen daar op de langere termijn mooie andere ontwikkelingen uit voort.

Laat ze hun gang gaan zou ik zeggen, technologische ontwikkeling FTW 😎

[Reactie gewijzigd door Jeanpaul145 op 22 juli 2024 23:55]

[delphium]

Een tech community splitst zich omdat een deel 1 ding wil en een ander deel iets anders wil dat niet compatibel is met wat de eerste groep wil. En vaak komen daar op de langere termijn mooie andere ontwikkelingen uit voort.

Vroeger dacht ik ook zo ;-) Maar uiteindelijk bereik je gewoon meer met samenwerken en goed nadenken voor je iets doet. Zie ook de reactie van @aaahaaap. Als je alles zelf compileert, kan je er nog voor kiezen om geen libsvg support in te bouwen, maar voor Debian geldt dus dat de gehele gebruikers community verplicht Rust moet installeren omdat de heren van libsvg zonodig op Rust wilden overgaan. Dan heeft je beslissing nogal impact!

[Jeanpaul145]

Maar uiteindelijk bereik je gewoon meer met samenwerken en goed nadenken voor je iets doet.

Dat is enorm context afhankelijk. Als het domein goed bekend is dan werkt 't op de korte en middellange termijn idd zo. Echter niet op de lange termijn, vanwege grotere ontwikkelingen die hele projecten overbodig kunnen maken.

Laat de meeste software echter zitten in een of ander half-verkend domein (een andere manier om dat te zeggen is: we doen nog steeds nieuwe ontdekkingen in dat domein), en dan kan splitsen ineens wel zin hebben, mits het enigszins gecoördineerd gebeurt. Want 1 kamp dat een innovatie wil proberen die niet kan omdat een ander kamp een mutueel exclusieve feature wil, kan nu z'n hart ophalen, het project forken en gewoon die feature ontwikkelen.

Geloof je me nog steeds niet? Ga dan maar eens naar een willekeurig project op GitHub.com en zoek naar de fork button 😉

Als je alles zelf compileert, kan je er nog voor kiezen om geen libsvg support in te bouwen, maar voor Debian geldt dus dat de gehele gebruikers community verplicht Rust moet installeren omdat de heren van libsvg zonodig op Rust wilden overgaan. Dan heeft je beslissing nogal impact!

De beslissing had zeker impact.
Echter was het niet zo zwart-wit, die versie van librsvg heeft bijvoorbeeld een lange tijd in unstable gezeten en andere package maintainers hadden dus alle kans om te testen.

Daarnaast is het zo dat de voordelen die Rust biedt betekenen dat toenemend veel software ervan gebruik zal maken, en Debian kan niet aan upstream developers gaan vertellen waar ze hun software in moeten ontwikkelen. Debian heeft te dealen met het feit dat ontwikkelaars dat lekker zelf bepalen.

Het is aan distros om samen te werken met de rust developers om in dit geval support voor meer arches toe te voegen.

Het is aan debían package maintainers om niet te gaan janken over arches die debian officieel helemaal niet support (maar in de praktijk wel werken).

En het is ook een goed idee om de gcc frontend voor Rust verder uit te bouwen. Hoewel ik daar een paar issues mee zie (bv dat het perpetueel achter zal lopen op rustc) heeft dat dan wel als voordeel dat Rust elke arch kan targeten did gcc kan targeten.

[Reactie gewijzigd door Jeanpaul145 op 22 juli 2024 23:55]

[delphium]

Ik ben het voor een groot deel met je eens hoor. Ik denk alleen dat het hoe dan ook toch tot een scheuring gaat leiden. Of dat erg is of niet, daarin verschillen we misschien wel iets van mening. De FOSS community heeft al een slechte naam gekregen door alle scheuringen, slplitsingen en forks die er zijn. Het wordt hier op Tweakers vaak gebruikt als argument tegen FOSS.

[Pinkys Brain]

Je installeert iets met libsvg en libsvg heeft een dependency, die verder geen impact heeft op de rest van het systeem behalve wat gebruikte opslag die vandaag de dag totaal niet relevant is, hoe heeft dat impact?

[Reactie gewijzigd door Pinkys Brain op 22 juli 2024 23:55]

[delphium]

En wat als je geen i686, x86_64 of ARM systemen hebt? Het gaat niet niet alleen om een enkele desktop gebruiker. Libsvg is een veel gebruikte systeembibliotheek. Daarnaast is Rust niet zomaar "een dependency". Het gaat om een complete programmeertaal die beschikbaar wordt op je systeem, vergelijkbaar met bijvoorbeeld Java. Dat wil je niet op je server hebben draaien als het niet absoluut noodzakelijk is.

[Pinkys Brain]

Je installeert de runtime.

Wat dan nog als je de compiler wel installeert, dat is puur van zichzelf geen aanvalsoppervlak (Java ook niet trouwens). Het draait niet op hogere privilege en is simpelweg niet aanroepbaar uit een ander programma zonder dat je op dat privilege niveau al uit het programma ontsnapt bent en arbitraire code kan uitvoeren, dan voegt toegang tot een compiler niks toe voor je exploit.

[Reactie gewijzigd door Pinkys Brain op 22 juli 2024 23:55]

[aaahaaap]

Het is ook een pain in the ass om de compiler te compilen. Rust is de enige compiler welke ik als binary heb geinstalleerd, ook alleen maar nodig voor libsvg

AFAIK is het gebruik van rust voor libsvg omdat de devs niet konden garanderen dat hun implementatie memory safe was als ze em in C deden. Ik weet niet helemaal wat ik daarvan moet denken. Aan de ene kant goed dat ze kritisch zijn op hun eigen kunnen en doorhebben dat ze fouten kunnen maken, aan de andere kant kun je je afvragen of ze dan uberhaupt wel kundig genoeg zijn onafhankelijk van de taal.

[Reactie gewijzigd door aaahaaap op 22 juli 2024 23:55]

[bzzzt]

Het is niet echt een geval van kundigheid, maar meer van het onvermijdelijke proberen te voorkomen. Zelfs de meest ervaren programmeurs hebben we eens een slechte dag, en juist dit soort garanties kan je prima 'machinaal' afdwingen. Een taal als C zit ook vol met boobytraps waarbij je het vrijwel onmogelijk is nooit fouten te maken wanneer je applicatie niet triviaal is.
Als je mensen over een 20 cm brede brug zonder leuningen stuurt vallen er meer af dan met leuningen. De oplossing is niet mensen gaan trainen dat ze minder vaak vallen, maar de leuningen toevoegen waardoor niemand meer valt.

[aaahaaap]

Je, fair enough, fouten maken is menselijk, dus altijd slim om na te denken over al dan niet technische mogelijkheden om dit te voorkomen. Vraag me alleen af of dat niet ook haalbaar was met een kleinere/incrementele verbetering ipv wisselen naar een andere taal.

[bzzzt]

Er zijn vast incrementele wijzigingen mogelijk, de vraag is alleen of je die nog een beetje logisch in de taal van verwerken zonder gelijk hele codebases over de kop te trekken.
Als voorbeeld: in Java is ooit een @Nonnull annotatie toegevoegd om null pointer exceptions te verminderen. Helaas is die annotatie optioneel, dus dat werkt niet in externe library code. Het is ook een annotatie, dus geen onderdeel van het typesysteem en moet er met een code checker uitgehaald worden. In de praktijk zie je dus weinig meerwaarde en nog steeds stapels exceptions. Rust heeft gewoon het hele 'null' concept uit de taal verwijderd. Dat lukt niet incrementeel.

[Pinkys Brain]

Er was Cyclone C, maar dat is doodgebloed.

Rust kwam op een perfecte tijd waar de illusie van controle eindelijk aan het afzwakken was en de implementatie goed genoeg was om zieltjes te winnen. Er is niks anders wat dichtbij productie klaar is, dus word het Rust.

[fretnn]

hier een overzicht van alle platformen die rust ondersteuning hebben:

https://doc.rust-lang.org...stc/platform-support.html

ter info: Je gelinkte artikel is 2.5 jaar oud, dit is toch wel een eeuwigheid voor een taal die volop in ontwikkeling is

Rust-kamp / C-kamp: idd, tegenwoordig moet je voor alles kiezen en wordt alles spijtig genoeg in kampen verdeeld

[delphium]

ter info: Je gelinkte artikel is 2.5 jaar oud, dit is toch wel een eeuwigheid voor een taal die volop in ontwikkeling is

Het artikel gaat dan ook niet over de taal Rust, maar over de impact die snelle adoptie van een nieuwe taal kan hebben. C bestaat immers al zeker 25 jaar langer dan Rust.

Begrijp me niet verkeerd, want ik vind Rust heel cool. Ik gebruik het zelf ook en ik heb verder geen problemen met het gebruik er van op mijn systeem. Het gaat meer om de enorme impact die zo'n wijziging met zich meebrengt en dat het dus zeer waarschijnlijk gaat leiden tot een scheuring.

[fretnn]

Ah Ik had niet door dat dit de insteek was. Ik las het vooral als kritiek op het feit dat er (toen) nog niet genoeg support was.

als rust gebruiker : heb je projecten die je gebouwd hebt online staan ? Altijd leuk om wat rust code te lezen en zo bij te leren.

[delphium]

als rust gebruiker : heb je projecten die je gebouwd hebt online staan ? Altijd leuk om wat rust code te lezen en zo bij te leren.

Helaas. Als absolute beginner heb ik alleen de projectjes uit het boek gemaakt en wat probeersels.

[Jeoh]

Het mooiste aan Rust is dat versie 1.69 op 4/20 uitkomt.

[jvdmeer]

Is dit een insider-joke? Ik begrijp 'm in ieder geval niet.

[Jeanpaul145]

Geen insider joke, gewoon een dosis onvolwassen humor 😂 (Google maar eens de termen 69en en 4/20)

[diondokter]

Nee, het is echt zo.
1.53.0 werd gisteren uitgebracht. Elke 6 weken komt een nieuwe versie.
Er zitten 16 versies nog tussen, dus 6 * 7 * 16 = 672 dagen.
Als je in de kalender checkt, dan zul je zien dat dat op 20 april 2023 valt. Puur toeval, maar wel erg grappig!

https://twitter.com/bitshiftmask/status/1405549491558682627

[Reactie gewijzigd door diondokter op 22 juli 2024 23:55]

[beerse]

Mijn grootste vraag is of er een Rust-naar-C compiler is. Toen ik in de vorige eeuw nog aan programmeren deed was er voor veel talen zoals C++ maar ook pascal en modula-2 een ...-naar-c compiler. Dat was toen makkelijker implementeren en eenvoudig poorten naar diverse platformen waar al een c compiler voor is.

Als die rust-naar-c compiler er (nog) niet is, is er dan al een rust-implementatie voor alle systemen waar al een linux kernel wordt gebruikt? dat zijn er best veel en ik ga er van uit dat ondersteuning voor diverse platformen niet zomaar wordt losgelaten.

[jj71]

Er is geen Rust-naar-C compiler voor zover ik weet. Dat probleem wat je beschrijft is op een andere manier opgelost: de Rust-compiler maakt gebruik van LLVM. Dat betekent dat Rust eerst naar de intermediate code van LLVM wordt gecompileerd, en die intermediate code kan dan vervolgens vrij eenvoudig worden vertaald naar de uiteindelijke machinecode van het doelplatform.

En omdat er al voor veel verschillende doelplatformen een LLVM code generator is, kun je je Rust-code op die manier compileren voor al die doelplatformen.

[Reactie gewijzigd door jj71 op 22 juli 2024 23:55]

[beerse]

Als rust nu gebruikt gaat worden voor de linux kernel omdat dan de fout-afhandeling en/of geheugen-beheer makelijker/eenvoudiger/strenger worden aangepakt: Gaan ze de hele kernel in rust schijrven?

Uit de vorige eeuw herinner ik mij de talen pascal en modula-2. Ook dat waren talen waarbij het de intentie was om daar kernels en systeem-programma's mee te schrijven. Met modula-2 is dat mij toen voor device-drivers ook wel gelukt. Maar uiteindelijk blijkt toch dat er bij de aansturing van echte hardware en/of op andere plaatsen toch weer iets nodig is dat net de beveiliging moet doorbreken. Dan ga je mooi nat met je betere beveiliging en dergelijke.

UIt de vorige eeuw herinner ik mij dat het wiskundig zelfs perfect zou zijn om de talen pascal of modula-2 te gebruiken, dan zouden er run-time geen fouten in zitten. Maar dan moet wel de originele pascal gebruitk worden. De populaire Turbo-Pascal had uitbreidingen in de taal die er juist voor zorgen dat het voor systeem-programmeren bruikbaar is maar tegelijk de wiskundige garantie verviel.

[Pinkys Brain]

Google wil betere module support, dus dit gaat waarschijnlijk om drivers. Ik neem aan dat Google overweegt om over een paar jaar al hun suppliers te dwingen Rust te gebruiken voor de drivers als het allemaal stabiel werkt.

Driver code is vaak bagger.

[Reactie gewijzigd door Pinkys Brain op 22 juli 2024 23:55]

[beerse]

Driver code is vaak bagger.

Er zijn heel veel redenen waarom hardware leveranciers de code van drivers niet vrij geven. Dit is volgens mij de grootste.

Voor mijn linux machines heb ik de meeste vertrouwen in open-source-drivers. Gewoon omdat er dan met een open blik en open mind naar gekeken is.

[MeMoRy]

Wat vind Linus Tovalds hiervan? Die wilde immers al geen C++ in de kernel. Alleen maar C.