Rust Core Team en Mozilla starten stichting voor Rust

Mozilla en het ontwikkelteam van Rust kondigen aan dat de programmeertaal zijn eigen stichting krijgt. Volgens de teamleden liep de huidige organisatie tegen steeds meer problemen aan door de groei en het succes.

Eind dit jaar moet de basis van een stichting gereed zijn, melden het Rust Core Team en Mozilla. Onder andere moeten verschillende merkrechten en domeinnamen met betrekking tot Rust en Cargo ondergebracht worden bij de stichting, evenals de financiële verplichtingen die hiermee gemoeid zijn.

De Rust-stichting moet duidelijker maken dat het om een onafhankelijk project met een eigen juridische identiteit en bankrekening gaat, wat onder andere moet helpen met het aantrekken van investeringen. Het is niet de bedoeling dat de stichting beslissingen gaat nemen die nu bij de ontwikkelteams liggen, zo maakten de initiatiefnemers vorig jaar bij het bekendmaken van de plannen duidelijk.

Rust heeft zijn oorsprong bij Mozilla Research. Bij het verschijnen van versie 1.0 kwam het project op eigen benen te staan. Het Rust Core Team meldt dat de aangekondigde ontslagen bij Mozilla ook bij Rust voor onrust hebben gezorgd. De invloed hiervan blijft beperkt, verwachten ze, omdat ontwikkelaars van Mozilla al onafhankelijk bijdroegen en dat ondanks hun ontslag waarschijnlijk blijven doen.

Rust is een programmeertaal die gericht is op prestaties, betrouwbaarheid en productiviteit en die onder andere door Mozilla, Discord en Microsoft ingezet wordt.

Reacties (62)

[Chris_147]

Na het nieuws van de bij Mozilla vreesde ik dat Rust daar veel negatieve gevolgen van zou ondervinden. Dit nieuws geeft hoop dat deze prachtige programmeertaal op zelfstandige basis verder kan gaan. Nu nog enkele andere grote investeerders en het loopt wel los.

Hier een artikel waarom Rust veel programmeurs enthousiast maakt: https://stackoverflow.blo...and-why-is-it-so-popular/

[PrisonerOfPain]

Ik, mijn bedrijf en mijn klanten gebruiken inmiddels zo'n 3 jaar Rust om nieuwe AAA-level game en rendering engines mee te bouwen en hebben er een hele codebase in opgebouwd, en zijn zelfs flink aan het investeren in contributies terug aan de rust compiler; de standard library en het algehele ecosystem.

We waren dan ook erg geschrokken door het nieuws dat Mozilla zo'n 250 man ontslagen heeft waarvan een groot deel Rust developers waren. Het is mooi om te zien dat het nu allemaal goed opgepakt is en dat er een hoop mensen een plek aan het vinden zijn waar ze alsnog aan Rust verder kunnen ontwikkelen.

Zelf zijn we enorm te spreken over Rust als taal (die een hele hoop fijne kleine en grotere features heeft die het ontwikkelen van stabiele software een heel stuk makkelijker maakt ten opzichte van C++) en Rust als community. Iedere keer dat ik met developers spreek die aan `rustc` of aanverwante projecten werken, ben ik aangenaam verrast over hoe open ze zijn om je te helpen.

We zijn dan ook erg blij met het het ontstaan van een Rust Foundation zodat het voortbestaan van de taal nog minder afhankelijk is van Mozilla.

[Zerfox]

Gaaf om te horen dat jullie zo veel gebruik maken van Rust in jullie rendering engine! Ik ben drie jaar geleden zelf ook bezig geweest hiermee, maar liep toen vaak tegen het probleem aan dat bepaalde Rust features alleen nog maar op de nightly versie te gebruiken waren waardoor soms er nog wel eens iets suboptimaal was.

Ik vond het een ontzettend fijne taal om mee te werken en zou zonder om te kijken C++ achter me willen laten. Zou je uit jouw persoonlijke ervaring alsjeblieft willen vertellen of Rust tegenwoordig volwassen genoeg is op de stable versie van de compiler? Mijn gevoel zegt van wel, aangezien ik naar aanleiding van jouw reactie er vanuit ga dat jullie niet professioneel op een experimental rust compiler werken. Ik wil voorkomen straks veel tijd en energie te steken in een code base waar vervolgens blijkt dat essentiële features alleen op nightly terug te vinden zijn.

[diondokter]

Eind 2018 is er een nieuwe 'edition' geweest. Die heeft heel wat dingen glad getrokken en verbeterd. Ik denk dat je nu een veel betere ervaring zal hebben als je het weer probeert.

[Zerfox]

Dankjewel voor je reactie! Ik ga het weer eens bekijken.

[PrisonerOfPain]

Het afgelopen jaar zijn we volledig op `stable` kunnen gaan draaien, daarvoor hadden we af en toe wel features nodig uit nightly. We hebben dit wel een hele tijd gedaan, en we CI-en al onze code met de laatste nightly om te kunnen checken dat nieuwe features onze code niet breaken.

[Zerfox]

Bedankt voor je reactie! Mooi dat jullie nu op stable kunnen draaien, dat klinkt veelbelovend. Ook slim om op die manier CI toe te passen. Ik ga er weer eens naar kijken

[jj71]

Ik, mijn bedrijf en mijn klanten gebruiken inmiddels zo'n 3 jaar Rust om nieuwe AAA-level game en rendering engines mee te bouwen en hebben er een hele codebase in opgebouwd, en zijn zelfs flink aan het investeren in contributies terug aan de rust compiler; de standard library en het algehele ecosystem.

Bedankt voor jullie bijdrage aan Rust!

Ik ben er sinds een maand of twee mee aan de slag als hobby, en net als velen ben ik ook erg enthousiast over Rust. Je hebt geen volledig handmatig memory management zoals in C++, en ook geen garbage collector zoals op de Java VM of zoals Go. De prijs die je daarvoor betaalt is dan wel dat de Rust compiler streng is, zodat je van tevoren gedwongen wordt goed na te denken over ownership en lifetimes van objecten. Maar dat helpt je wel om goede, foutloze code te schrijven.

Dus ik ben ook blij dat met de Rust Foundation het in ieder geval minder afhankelijk zal zijn van de businessgrillen van Mozilla - want deze mooie taal mag niet verloren gaan.

[Verwijderd]

Misschien iets te off-topic, maar ga het toch vragen:

Hebben jullie een voorkeur voor embeddable scripting-talen in jullie engine? Rhai, rlua, etc... ?
Wat zijn jullie ervaringen hiermee?

[ari3]

In een notendop is Rust gewoon C met ingebouwd geheugenbeheer. Ik zie vooral nut voor het bouwen van veilige commandline tools zonder buffer overflows. De tool-chain er omheen is wel wat mij tegenhoudt het echt te gebruiken want daar zit een groot not-invented-here-principe in: eigen repositories, eigen package systeem, eigen project descriptors, enz. Allemaal dingen die al jaren geleden opgelost zijn voor andere programmeertalen.

[Devil N]

In een notendop is Rust gewoon C met ingebouwd geheugenbeheer.

Hiermee sla je de plank toch wel enigszins mis. Rust heeft geen geheugenbeheer zoals bijvoorbeeld Go (garbage collection) of Swift (automated reference counting) dat wel hebben. Rust laat je net als C/C++ data op de stack of op de heap alloceren en verwacht dat je zelf het beheer hierover voert. Daarnaast bevat de standard library ook een implementatie van reference counting, mocht je dat willen gebruiken. Garbage collection zal vast ook wel bestaan, maar dat is IMHO niet waarom je voor Rust kiest.

Wat Rust uniek maakt is dat het hele strikte regels heeft omtrent eigendom van data en delen van data. Ieder stuk data wat je aanmaakt heeft ten alle tijden exact één duidelijk gedefinieerde eigenaar die de verantwoordelijkheid voor dit stuk geheugen op zich neemt. Eigenaarschap kan overgedragen worden (move) of de data kan uitgeleend worden (borrow). Dit dwingt je om goed na te denken over de verantwoordelijkheden binnen je code, en voorkomt problemen zoals null pointers. Mutability is ook sterk beperkt; in tegenstelling tot C++ zijn 'const' references de standaard in Rust, en mag je slechts één mutable reference tegelijkertijd in leven hebben. Dit voorkomt veel gevallen van race conditions en maakt threading een stuk makkelijker. Als je ergens een reference wilt bewaren naar een stuk data, dan moet de lifetime van deze data duidelijk gespecificeerd worden, zodat je geen dangling pointers kunt veroorzaken. Dit alles wordt at build-time middels static analysis gecontroleerd door de compiler.

Bovenstaande is ook allemaal mogelijk in C++ maar vereist een hele strenge discipline van de programmeurs en het is heel makkelijk om hier fouten in te maken. De syntax en semantics van Rust maken van deze discipline het uitgangspunt en de compiler garandeert dat je deze fouten niet maakt. Rust voelt in het begin enigszins beperkend, maar het maakt een enorm scala aan veelvoorkomende bugs praktisch onmogelijk.

[Katsunami]

Bovenstaande is ook allemaal mogelijk in C++ maar vereist een hele strenge discipline van de programmeurs en het is heel makkelijk om hier fouten in te maken. De syntax en semantics van Rust maken van deze discipline het uitgangspunt en de compiler garandeert dat je deze fouten niet maakt. Rust voelt in het begin enigszins beperkend, maar het maakt een enorm scala aan veelvoorkomende bugs praktisch onmogelijk.

Als je echter goed kunt programmeren in C of een andere taal waarin je zelf je geheugen moet beheren, en hierin een goede, stricte discipline hanteert, dan voelt Rust heel logisch. Zelf heb ik tijdens mijn opleiding niks anders gedaan dan C en C++ (Hogere Informatica met als specialisatie Embedded Systems), en daarna lang in C geprogrammeerd in een ADT-stijl

Voor mij voelde Rust aan als een hele logische taal, en mij geeft hij de zekerheid dat als het compileert, het geheugenbeheer in orde orde is. Als je werkt met iterators en containers waar mogelijk, komt zelfs "index out of bounds" niet meer voor.

Voor mij was Rust geen meilijke taal om mee te beginnen. Hetgeen ik enkel een beetje gekunsteld vind aanvoelen zijn dingen als "unwrap_or" en "unwrap_or_else" en dergelijke. Een beetje een vreemdsoortige versie van een null-coalescing operator in een taal die geen NULL zou moeten hebben...

[PrisonerOfPain]

Sinds `?` gestandaardiseerd is, vallen `unwrap_or` en dergelijke ook enorm mee.

[Devil N]

Ik had precies dezelfde ervaring. Persoonlijk heb ik geen moeite met zelf geheugen beheren en een strikte discipline vast te houden. Rust voelde voor mij ook al snel aan als heel logisch, alhoewel er wel een periode van wennen aan vast zat. Ik ben ook erg te spreken over Rust, het is een taal die perfect past bij mijn manier van denken.

Het ding is alleen dat je meestal met een team aan een project werkt en niet iedereen even goed is in die discipline. Dat leidt vaak tot onnodige fouten, technical debt, extra werk, en veel frustratie onderling. Als ik toch een stuiver zou krijgen voor iedere NullReferenceException in C# die ik heb moeten oplossen door anderman's slordigheid... Het feit dat Rust iedereen dwingt om goed na te denken over zijn of haar code en het moeilijk maakt om zomaar iets in elkaar te flansen, dat is wel erg fijn.

[mathijs727]

Het "package systeem" (gebrek aan een defacto package manager) is juist één van de grootste bronnen van hoofdpijn met C en C++. Iedereen gebruikt wat anders en dikke kans dat niet alle packages die je wilt gebruiken allemaal op dezelfde package manager beschikbaar zijn (de enige die in de buurt komt is vcpkg). Build systemen is ook zo'n iets. Gelukkig is CMake nu erg populair maar er zijn nog steeds packages (bijvoorbeeld Intel Threaded Building Blocks) die nog steeds aan Makefiles vast houden. Op Windows betekent dat dus een hoop extra ergernis (msys2 installeren...). Dit is al helemaal een nachtmerrie wanneer je zelf aan een library werkt die ook weer door andere mensen gebruikt moet gaan worden (dan moet iedereen die jou library wilt gebruiken eerst alle benodigdheden voor TBB binnenhalen).

Het standardizeren van het build systeem + package manager is juist één van de sterkste kanten van Rust (ten opzichte van C/C++)!

[woutertje]

Ben wel benieuwd of je hier wat meer over kunt zeggen. De toolchain van Rust is imho juist een van de grote pluspunten. Geen (geprutst met) makefiles en makefile generators, maar een goed werkende geintegreerde toolchain waar dependencies op een strakke manier geregeld zijn.

Naast het geheugenbeheer, de toolchain is ook thread safety een speerpunt waar Rust grote stappen heeft gezet.

[Katsunami]

Hm.... let me see...

Rust-project:
git clone <repo>
cargo build --release

En klaar. Cargo downloadt alle dependencies (en dependencies van dependencies), en maakt dan een build aan de hand van de opties in cargo.toml van het project en de toolchain die je geinstalleerd/geactiveerd hebt. Als een project gebruik maakt van stable Rust, dan werkt dit nagenoeg altijd.

C++-project:
git clone <repo>
make
....

Dan krijg je waarschijnlijk 300 errors. Grote kans dat je niet de juiste compiler hebt geinstalleerd van de 32 beschikbare opties, of je make-file houdt geen rekening met specifiek NET DAT ding dat nodig is voor jouw geïnstalleerde toolchain... zelfs als dat allemaal goed is, dan missen er waarschijnlijk dependencies waardoor het compileren niet lukt, en nadat je een dependency hebt opgezocht en *just so* hebt neergezet met *precies deze* opties voor dat project, blijkt dat die ook weer een dependency heeft... enzovoorts. Soms kan het letterlijk uren duren voordat je een groot C++-project daadwerkelijk gecompileerd krijgt.

Het enige waar ik geen fan van ben met Rust is de afhankelijkheid van crates.io (net zoals NPM afhankelijik is van het NPM-repo). Wat ik graag zou willen is iets als dit:

cargo download-deps <mapnaam>
rustup create-installer full 1.45 <mapnaam>

Dan zou Cargo alle dependencies kunnen downloaden naar die map, waarna je in cargo.toml kunt aangeven dat die map gebruikt moet worden in plaats van crates.io. rustup zou een installer kunnen bouwen van een specifieke versie van Rust, met alle componenten erin.

Als je dan jouw code hebt, de map/zip met dependencies en de installer, dan kun je het project ook nog compileren over 20 jaar, mits je een computer hebt waar de compiler op draait.

Nu zou het kunnen gebeuren dat het project incompatible wordt met zijn dependencies; ik ga er niet van uit dat crates.io alle versies van alle dependencies voor altijd en altijd bewaart (en dat crates.io voor altijd bestaat).

Misschien is iets dergelijks wel nu beschikbaar. Ik heb verscheidene keren berichten gezien dat aan iets als dit gewerkt wordt, maar ik heb het niet meer in de gaten gehouden. (Ik schrijf op dit moment enkel één programma in Rust, als hobby; omdat ik niet C wil gebruiken. En Go al helemaal niet.)

===

Oh, en als je vindt dat Rust "net C is maar dan met veiliger geheugenbeheer", dan zit je er op dat gebied flink naast.

Rust is niet OOP; het gebruikt een abstract-data-type (ADT)-structuur op basis van structs, zoals je die in C ook zou bouwen om "pseudo-objectgeorienteerd" te programmeren, maar Rust doet dat veel netter. Dat is echter voor mijn gevoel waar de overeenkomst met C eindigt. Rust heeft VEEL meer concepten dan C en is op het gebied van types en dergelijke veel stricter; het komt veel meer in de beurt van C++, maar dan dus pseudo-objectgeorienteerd.

En dan heb ik het niet eens over het feit dat Rust memory safe, thread safe en race condition safe is, zolang je geen "unsafe { }"-blocks gebruikt... en dat de compiler je al van te voren kan vertellen dat code niet betrouwbaar gaat werken. (Rust-analyzer kan het tegenwoordig zelfs vaak al in de IDE.)

[Reactie gewijzigd door Katsunami op 23 juli 2024 00:57]

[laserve]

Ben eigenlijk ook wel benieuwd naar een vergelijking tussen Rust en Go. Vullen die hetzelfde gat?
Go is toch ontworpen door één van de ontwerpers van C dus als je C wilt met GC, boundschecking, unicode en string handling lijkt me dat een logischere keuze,

[Devil N]

Go en Rust komen allebei voort vanuit dezelfde wens om een modern alternatief voor C/C++ te bieden voor systems-level programming, maar zijn daarbij hele andere richtingen op gegaan.

Rust legt de nadruk vooral op memory safety en thread safety, en is bereid om concessies te doen op het gebied van gebruiksgemak om zo goede garanties te kunnen geven over de robuustheid van de code. Daarnaast doet Rust qua performance vrijwel niet onder voor C en C++.

Go daarentegen legt de nadruk meer op productiviteit, met snelle compilatie- en iteratietijden en automated memory management in de vorm van garbage collection, wat wel enigszins ten koste gaat van run-time performance. Go voelde voor mij een beetje aan als Python qua ease-of-use, maar dan met de bijkomende voordelen van een statically typed en native compiled taal als C.

Beide talen zijn uitstekend maar ze bedienen wel ieder hun eigen niche. Welke taal het beste is hangt helemaal af van jouw situatie, wat de eisen zijn van het project en wie de programmeurs zijn die eraan werken.

[Flex-Ible]

Qua runtime is het grootste verschil dar Rust geen garbage collection systeem heeft maar een handmatig memory management model. Dit betekent dat het doorgaans sneller is dan Go omdat er dus geen garbage collector op de achtergrond draait. Daar staat tegenover dat handmatig memory management vaak lastiger is te programmeren er dus meer tijd in het ontwikkelen van de applicatie gaat zitten. Eigenlijk hetzelfde verhaal als bij C/C++ vs Go/Java/C#. Waar Rust zich onderscheid van C en C++ is dat de compiler voor je kan controleren of je geen fouten hebt gemaakt in het managen van geheugen waardoor je applicatie minder snel een memory leak zal hebben en vat is voor buffer overflow aanvallen.

Op gebied het structureren van je code lijken ze initieel wel op elkaar. Geen van beide zijn object georiënteerd en werken in plaats daarvan met structs en methodes die je aan die structs kunt verbinden. Misschien dat je dan gelijkt denkt aan een klasse met methodes maar Rust en Go kennen vervolgens geen inheritance of polymorfisme.

Go heb ik niet heel veel mee gewerkt dus ik weet niet zo veel af van verdere mogelijkheden die de taal bied maar wat ik wel weet is dat Rust generics geeft waar Go dat niet heeft. Dit is een manier om je functies, structs en methodes te laten werken op meerdere datatypen zolang deze bepaalde functionaliteit implementeren. Misschien dat je dit al kant vanuit Java welke ook generic methods heeft. De Rust versie van generics is een uitgebreide variant hiervan.

[Katsunami]

- Go heeft een garbage collector, Rust niet
- Go is veel trager dan Rust (vanwege, met name, de garbage collector)
- Go heeft geen generics
- Go heeft nog steeds NULL / nil-waarden, Rust niet (die gebruikt daarvoor Option<T>)
- Go gaat voor simpel: als het niet simpel kan, dan kan het niet / implementeren ze het niet
- Go heeft het voordeel dat het door een enorm bedrijf wordt gesteund (Google)

Voor mij voelt Go aan als "C voor het internet, met een garbage collector". Niet zo vreemd ook, als je ziet wie de ontwerpers zijn. (Ken Thompson, Rob Pike.)

Begrijp me niet verkeerd... Ken Thompson is een idool voor mij op verschillende gebieden (Unix, C, schaakcomputers...), maar misschien was het niet het beste idee om hem aan te stellen voor het ontwerpen van een programmeertaal voor de toekomst.

Hij was toen er met Go begonnen werd een jaar of 67 (en ondertussen 77), hij heeft 45-50 jaar ervaring in het schrijven van C, en het is in mijn ogen niet verrassend dat Go aanvoelt als C met wat nieuwerwets spul erin om het bruikbaar te maken op het internet.

Hetgeen ik het meest jammer vind is dat de twee dingen die Go als voordeel heeft (simpel, ondersteund door een groot bedrijf als Google) ervoor zorgt dat deze taal veel sneller wordt opgepakt dan Rust. Tegenwoordig begint Rust een beetje in te lopen, maar er blijven nog steeds geluiden klinken van "oh wat is het moeilijk", en "wat is die borrow checker lastig". En de meeste mensen gaan voor de weg van de minste weerstand. Daarom zijn (in mijn ogen brakke) talen als PHP, Javascript, en PHP zo populair.

Eigenlijk durf ik wel te stellen dat, indien Rust 'te moeilijk' is voor iemand, de basis qua informatica en computerkennis van die persoon te zwak is. Als je onder de knie hebt hoe een computer met geheugen (stack, heap), zijn CPU (registers, cache lines) en de basis van dingen als multi-threading snapt, dan is Rust niet moeilijk... dan is het uiterst logisch.

Ik heb begrepen dat deze zaken in moderne informatica-opleidingen nauwelijks meer wordt gegeven, want "niemand gebruikt dat nog c.q. hoeft dat nog te weten, want alles gebeurt toch op het internet en de cloud". Totdat er dingen zijn die niet op het internet of in de cloud gebeuren, of dat blijkt wanneer programmeertalen als Python of PHP voor sommige workloads gewoon VEEL te traag zijn.

Zoek maar eens rond naar (onder andere) Discord, die delen van hun backend zijn gaan herschrijven in Rust, en daarbij een vermindering van honderden MB's aan RAM-gebruik per proces en vele keren aan snelheid hebben gewonnen, waardoor ze DUS veel minder bronnen nodig hebben in de cloud, en DUS heel ver kunnen terugschalen en DUS heel veel geld besparen...

Wat mij betreft zijn talen als Rust (en andere talen gestoeld op dezelfde filosofie), de enige juiste manier voorwaarts om grote projecten EN beheersbaar, EN veilig, EN snel te houden.

[PrisonerOfPain]

Go is een heel stuk trager dan Rust, en heeft een GC die Rust niet heeft

[Gropah]

Go en Rust worden vaak met elkaar vergeleken, maar ik snap nooit zo waarom. Het zijn allebei relatief nieuwe spelers en ze hebben allebei een goede hoeveelheid gebruikers, maar ze springen allebei in een ander gat.

Rust is voornamelijk voor snelle performance op het systeem zelf, waar Go meer als C voor het web/de cloud word genoemd. Veel grote projecten die in die omgeving veel gebruikt worden (zoals Kubernetes, grafana maar ook influxdb), zijn geschreven in Go.

[berchtold]

Rust FTW, beste programmeertaal ooit.

[84hannes]

Rust is heel interessant maar wat nu nodig is is ondersteuning en aspiratie. Ik zou het graag voor embedded systemen gebruiken maar ten eerste wordt onze processor nog niet ondersteund en ten tweede kan ik mijn werkgever niet overtuigen een relatief nieuwe taal te gaan gebruiken voor systemen die nog decenialang onderhouden moeten worden. Hopelijk kan de nieuwe stichting hierin helpen.

[PrisonerOfPain]

Mijn bedrijf, en een van mijn klanten (Embark Studios) zijn vrijwel volledig op Rust overgestapt omdat het voor ons een heel serieus alternatief voor C++ begon te worden. Vooral nu zowel Mozilla, Microsoft, Facebook, Google (als onderdeel van Fuchsia) het gebruiken en ze zelfs voor de Linux kernel Rust aan het overwegen zijn zou het een mooie tijd zijn voor je werkgever om hier over na te denken.

Wij zijn er wil ingestapt, wetende dat we een hoop zullen moeten contributen aan verschillende project; we hebben discussies lopen met het Rust Language Team, sponsoren rust-analyzer, contributen aan cargo en andere projecten (cargo-apk, cargo-dinghy etc) om platform support beter te krijgen voor platformen die voor ons relevant zijn.

[84hannes]

Facebook, Google etc zijn softwarebedrijven. Als zij een stukje software in Rust schrijven (het gaat vooralsnog om relatief kleine delen) dan kunnen ze dat risico hanteren. De interfaces zijn waarschijnlijk goed gedefinieerd dus zelfs als Rust over een paar jaar niet genoeg ondersteuning meer heeft dan herschrijven ze dat stukkie.
Wij krijgen soms bug reports van software die al meer dan 15 jaar geleden is geschreven. Die code weer gecompileerd krijgen is genoeg uitdaging zonder exotische talen. Dus als Rust op een dag niet meer exotisch is zou het kunnen, maar tot die tijds is het niet realistisch, helaas.

[4bit]

Ik heb enkele maanden ook gekeken naar embedded rust. Hiervoor het embedded rust book gevolgd en het gebruikte devkit gekocht. Zeer mooie toolchain, door middel van Cargo en dergelijke wordt er heel veel voor je klaar gezet, git repo, testen, documentatie generatie, eenvoudig targets toevoegen.

Tegenover C en dergelijke is dit wel een omgeving dat stukken moderner aanvoelt dan zelfs de dure embedded C omgevingen (keil, IAR, ...). Waar ze tot op vandaag nog niet van TDD, CI/CD, ... hebben gehoord, en eigenlijk 15 jaren zijn blijven stilstaan.

Daar tegenover staat wel dat rust (zeker embedded rust) nog allemaal nieuw is. Dus op dat vlak volg ik je werkgever wel. Ik vind het al interessant voor hobby projecten, maar om het op mijn werk voor te stellen of effectief te gebruiken vind ik het nogal pril. Mogelijks is het al zeer stabiel, maar heb het gevoel dat heel het embedded rust project nog redelijk onder ontwikkeling is.

Maar ik ben gewoon al tevreden dat er eindelijk werk wordt gemaakt van moderne tools voor de embedded programmers. Lijkt mij dat er in ieder geval een zeer slim team aan werkt. Dewelke ook goede en uitgebreide documentatie maakt.

[roelboel]

Rust lijkt me fantastisch voor embedded toepassingen. Ik duim voor je dat je er mee aan het werk kan gaan!

rustc gebruikt toch LLVM? Wat voor een exotische processor gebruiken jullie? Of ligt het ergens anders aan?

[PrisonerOfPain]

Zelf ff support inbouwen

[Faeron]

Zeggen dat Rust beter is dan (bijvoorbeeld) C is even onzinnig als zeggen dat Frans beter is dan Spaans.

[YopY]

Nee, je kunt objectief zeggen of een taal beter is dan de andere; C/C++ doen het slecht met betrekking tot geheugenbeheer, waardoor we al jarenlang elke dag wel grote (security) bugs vinden, o.a. in browsers. Je kunt de developers de schuld geven, maar als de taal het makkelijk maakt om onveilige software te schrijven moet je je toch even achter de oren krabben.

[woopdiedoo]

Klinklare onzin. Rust is objectief beter dan C/C++ omdat het sterker is in veiligheid? Je noemt hier slechts een aspect van een programmeertaal. Wat als veiligheid voor een bepaald programma niet zo relevant is, omdat het bijvoorbeeld weinig tot geen (onvertrouwde) input verwerkt? Tegelijkertijd produceert Rust grotere binaries, wat objectief gezien slecht is en misschien in sommige omstandigheden zwaarder weegt. Hoe zit dat dan?

Als het mogelijk was om een programmeertaal te creeeren met al het goede en niks van het slechte, was dat al lang gebeurt. In werkelijkheid moeten er altijd concessies gedaan en overwegingen gemaakt worden. Dat leidt er toe dat voor sommige projecten de ene taal handiger is, en voor andere projecten een andere taal. Bovendien zullen sommige dingen altijd aankomen op mening. Hier in deze comments bijvoorbeeld zie ik zowel voorstanders als tegenstanders van Rust's packaging systeem.

[Katsunami]

De developers de schuld geven is te gemakkelijk...

Ik heb altijd van mijzelf gevonden dat ik goed tot zeer goed was in het schrijven van veilige software zonder geheugenlekken en race conditions. Dat heb ik echter nooit echt ergens mee kunnen bewijzen, behalve de volgende dingen, betreffende de systemen waaraan ik heb gewerkt (embedded software, projecten van 1-2 personen):

- De systemen crashen niet of zeer zelden.
- In dagenlange testen komen er geen geheugenlekken bovendrijven (geen toename in geheugengebruik).
- Geen deadlocks of andere problemen met threading.

Ik moet wel zeggen dat, omdat het embedded software is, de code niet heel groot is. Een paar duizend regels, en dat is het dan meestal wel om het een of andere apparaat aan te sturen. En, uuh... ik ben geen snelle programmeur als ik met dit soort dingen bezig ben. Verre van. Zeg maar ronduit traag, in vergelijking tot wanneer ik iets zou moeten schrijven in bijvoorbeeld PHP, als je telt in "regels werkende code per dag" (wat dan weer niet de meest geweldige metric is, maar ok...)

Rust voelde voor mij een bevestiging van mijn kunnen op dat gebied: als mijn code niet veilig zou zijn, dan zou ik sinds dag 1 zwaar in de clinch gelegen hebben met de borrow checker. Dat was echter niet het geval; ik ben gewoon begonnen, en ik heb de borrow checker maar een paar keer ontmoet.

Het is voor mij veel lastiger om idiomatisch Rust te schrijven ("zoals het hoort in Rust", in plaats van "net C met Rust syntax"), dan om veilige code te schrijven.

Desalniettemin... ik ben *WEL* een paar keer door de borrow checker op de vingers getikt op onverwachte momenten. Dat betekent dat ik na jaren ervaring nog steeds fouten kan maken op het gebied van geheugenbeheer en threading, en Rust c.q. de borrow checker stipt die fouten onvermijdelijk aan.

Het is dus aannemelijk dat sommige van de oudere systemen waaraan ik heb gewerkt *wel* bugs bevatten, maar dat die in de dagelijkse praktijk (nog?) niet komen bovendrijven... (en als ze dat al doen: ik werk niet meer bij de bedrijven waarvoor ik die systemen vroeger heb geschreven.)

[Reactie gewijzigd door Katsunami op 23 juli 2024 00:57]

[ACM]

Je zou toch wel hopen dat Rust objectief gezien beter is dan C of C++, aangezien het toch wel enigszins bedoeld is als taal die veel van de problemen die C/C++ met zich meebrengen oplost. Of zie ik dat verkeerd?

Er zijn in de praktijk vast wel scenario's waar C/C++ beter is, of dan in ieder geval het ecosysteem daarvan.

[GertMenkel]

Rust is voor embedded development momenteel nog zeer onhandig. Je kunt het gebruiken op een aantal bordjes, maar prototyping op platformIO is echt vele malen makkelijker dan een eigen toolchain moeten compilen (die achterloopt) als die al bestaat (aangezien LLVM niet zomaar code van fabrikanten inbakt als ze geen beloftes willen doen over het onderhouden daarvan).

De taal leent zich er ook niet bepaald voor, omdat veel acties (GPIO etc.) werkt met memory-mapped IO, en arbitraire geheugen-writes is nou net iets wat Rust wil voorkomen. Er zijn workarounds voor, maar het geheel is in C gewoon een stuk makkelijker.

[PrisonerOfPain]

Unsafe code voor het schrijven naar memory mapped IO of andere fratsen die je nodig hebt op een embedded systeem zijn dan ook niet echt te voorkomen (en vaak nodig). We hebben in onze codebases redelijk wat unsafe code, alleen hebben we het voordeel dat de "unsafe-ness" beperkt blijft tot precies die plekken en de rest van de codebase wel gewoon safe is.

[GertMenkel]

Dat klopt, maar het is toch een reden dat de taal niet echt optimaal is voor zo'n omgeving. Het ecosysteem is er momenteel ook niet op gebouwd.

Er worden wel grote stappen gemaakt, en de embedded engineering wereld loopt vaker jaren achter op de normale softwarewereld als het op toolchains aankomt. Met een paar jaar zal het vast beter gesteld zijn met de ondersteuning van Rust op embedded, maar momenteel zou ik het alleen embedded gebruiken om mee te spelen, niet voor iets belangrijks.

[84hannes]

19 augustus 2020 13:58
Dat klopt, maar het is toch een reden dat de taal niet echt optimaal is voor zo'n omgeving.

Ik zie dat heel anders. Iedereen die in deze eeuw heeft leren programmeren heeft wel eens te horen gekregen dat abstractie goed is. Als je alle low-level code doorspekt met unsafes dan is dat het deel waar eventuele geheugenbugs zich zullen bevinden. In de hogere lagen kun je unsafe daardoor zoveel mogelijk vermijden. Met C kun je vanuit de GUI/database/websocket direct memory mapped I/O aanspreken maar vrijwel iedere architect zal dat een slecht idee vinden. Dat dat met Rust onergonomisch is is niet een bewijs dat Rust ongeschikt is voor embedded: het is een reden om het te gebruiken voor embedded.

[BikkelZ]

Nee hoor. Sommige programmeertalen zijn gewoon kut, zoals Java of JavaScript. Het is vrij eenvoudig te bewijzen dat de hoeveelheid moeite die je moet steken om een programma van een bepaalde omgang te bouwen groter is dan bij andere talen en de resulterende correctheid van die programma's met name in JavaScript gewoon problematisch is. Je ziet ook niet voor niets dat voor beide talen allerlei alternatieven hebben (Coffeescript, Kotlin, etc) waar andere programmeertalen (C#, Python of zelfs PHP) niet of nauwelijks een markt kennen voor verbeterde varianten.

C is nog een voorbeeld waarvoor constant alternatieven uitgevonden worden, zoals Objective-C, C++, D en nu weer Rust (hoewel Rust eigenlijk meer de opvolger is van C++). Dat komt omdat er gewoon gaten in het ontwerp zitten van de taal die veroorzaakt werden door de realiteit in de jaren '70 waarbij 8KB geheugen een luxe was. Rust maakt gebruik van het feit dat een compiler Gigabytes aan geheugen en meerdere GHz+ cores tot zijn beschikking heeft.

[Guus Leeuwis]

"I love French wine, like I love the French language. I have sampled every language, French is my favorite. Fantastic language. Especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'enculé de ta mère. It's like wiping your arse with silk. I love it." (geintje)

[edit] dit is toch geen -1 waard??

[Reactie gewijzigd door Guus Leeuwis op 23 juli 2024 00:57]

[roelboel]

Sorry, de werkelijke wereld is niet zo eenvoudig als de door jou ingebeelde. Er is geen wereld waar een "beste programmeertaal" bestaat.

Er zijn domeinen waar Rust zeker een toepassing heeft, en op andere plekken gaan we Rust niet tegenkomen. Niet iedereen heeft de nadelen van een borrow checker nodig waar garbage collection volstaat. Zelfde geldt voor statische versus dynamische typing.

Talen hebben eigenschappen, toepassingen hebben eisen. Er zijn veel verschillende toepassingen, en daarom zijn er veel verschillende talen. Dat zal zo blijven.

[SPee]

Ik zie best wel wat verbeteringen die ze kunnen doen. De gedachte erachter is goed (memory ownership), maar de syntax kan beter.

[:murb:]

Het Rust Core Team meldt dat de aangekondigde ontslagen bij Mozilla ook bij Rust voor onrust hebben gezorgd. De invloed hiervan blijft beperkt, verwachten ze, omdat ontwikkelaars van Mozilla al onafhankelijk bijdroegen en dat ondanks hun ontslag waarschijnlijk blijven doen.

Hmm... zolang ze met Rust kunnen blijven werken wel. Stel dat ze een baan accepteren waar ze voornamelijk in een andere taal moeten werken vrees ik dat hun 'vrijwillige' bijdrage ook sterk zal dalen. De Servo-ontwikkeling was toch wel een van de drijvende krachten achter Rust, of is dat inmiddels anders?

[PrisonerOfPain]

Ik heb persoonlijk contact gehad met een aantal van de developers die hierdoor getroffen zijn en de meeste willen vooral een baan accepteren waardoor ze fulltime aan Rust kunnen werken.

[HollowGamer]

Het zou mooi zijn als de developers zouden kunnen werken voor de aankomende Rust stichting zoals bij Qt het geval is. Helaas hebben zij het ook moeilijk financieel, dus voor een stichting blijft het wellicht net een stap te groot, tenzij MS, Mozilla, etc. bedragen kunnen blijven overmaken.

Het is best jammer dat er zo weinig developers echt vast in dienst zijn, vrijwel altijd onder een andere flag zoals bij Redhat of MS.

[-jacQues-]

"de aangekondigde ontslagen bij Mozilla ook bij Rust voor onrust hebben gezorgd."
Wellicht onbedoeld grappig, maar ik moest er om lachen.

[Maurits van Baerle]

Ik hoop wel dat Mozilla financieel beter wordt van Rust, ook als het in een aparte stichting wordt geplaatst. Het succes van Rust zou nou juist een mooie extra inkomstenbron kunnen zijn voor Mozilla om andere projecten (van Firefox tot MDN Docs en van de Mozilla Location Service tot Common Voice in leven te kunnen houden.

Hoe zou dit er uit moeten zien? Ik weet het niet precies maar ik kan me bijvoorbeeld voorstellen dat Mozilla dé uitgever zou kunnen zijn van Rust boeken, handleidingen, cursussen etc.

[PainkillA]

Wat ik persoonlijk nog erg mis tegenover Go is bijv een echt goede IDE zoals goland van jetbrains ipv geneuzel met 3rd party plugins in vscode ofzo. Ook is het ecosysteem nog dermate klein dat verschillende vlakken gewoon niet snel en soepel te maken zijn zoals https://www.arewewebyet.org/ ook aangeeft voor web ontwikkeling

[roy.jacobs]

Jetbrains heeft officiele Rust support in CLion.

[jj71]

Jetbrains heeft een Rust plugin die werkt in CLion en ook in IntelliJ (alleen heb je in IntelliJ, voor zover ik weet, dan wat minder features, zoals een debugger voor native code).

In mijn werk programmeer ik vooral Java met IntelliJ, wat een supergoede IDE is voor Java, met allerlei handige automatische refactoring tools.

Met Rust ben ik eerst begonnen met VSCode en een Rust-plugin, maar daar merkte ik al snel dat VSCode geen echte IDE is. Heel vaak snapt 'ie de code gewoon niet en krijg je bijvoorbeeld geen of verkeerde suggesties als je met Ctrl+Space wilt aanvullen.

Daarna ben ik overgestapt op CLion met de Rust-plugin van Jetbrains en dat is al een heel stuk beter dan VSCode, maar toch zijn er nog veel punten waarbij je merkt dat het allemaal nog lang niet zo goed is uitgewerkt als IntelliJ voor Java. Voor veel soorten fouten in de code geeft de IDE geen waarschuwing, pas als je de code compileert dan krijg je een foutmelding; en niet alle refactoring tools die ik gewend ben voor Java werken ook voor Rust.

[Qmier]

Ik ben ook zeer blij met dit nieuws, ik ben toevallig recentelijk begonnen met rust om back end applicaties en communicaties engines mee te maken, waar ik nu nog c# voor gebruik. Dus toen ineens dat nieuws van Mozilla binnenkwam, was ik al bang dat ik voor niks me verdiept had in rust. Toevallig ook via Tweakers op rust uitgekomen.

[3dfx]

Ja, ik ook, dit stukje uit het artikel vond ik toch wel verontrustend:

Het Rust Core Team meldt dat de aangekondigde ontslagen bij Mozilla ook bij Rust voor onrust hebben gezorgd.

[Blokker_1999]

Letterlijk de eerste zin:

Mozilla en het ontwikkelteam van Rust kondigen aan dat de programmeertaal zijn eigen stichting krijgt.

[AMD and INTEL]

Nee, de programmeertaal zoals in het artikel staat

[ro8in]

Waarom lees je het dan niet eerst?