Google steekt miljoen dollar in verbeterde interoperabiliteit tussen Rust en C++

Google investeert een miljoen dollar in de Rust Foundation om de interoperabiliteit tussen Rust en C++ te verbeteren. Google hoopt dat de adoptie van Rust in de ontwikkelgemeenschap daarmee verder uitgebreid wordt.

Het geld is specifiek bedoeld voor het Interop Initiative van de Rust Foundation. Dit initiatief heeft als doel naadloze interoperabiliteit tussen bestaande C++-code en Rust-code mogelijk te maken. Dit is belangrijk voor organisaties die geleidelijk aan migreren naar Rust, aldus de Rust Foundation in een aankondiging.

Verschillende bedrijven stappen over van C++ naar Rust, vooral omdat Rust minder geheugenfouten veroorzaakt. Veel kwetsbaarheden in Google-producten worden veroorzaakt door geheugenfouten. Google sloot zich daarom in 2021 bij de Rust Foundation aan en heeft de taal sindsdien geïntroduceerd in onder meer Android en Chromium. "Rust is een van de sterkste tools die we hebben om beveiligingsproblemen als gevolg van geheugenfouten aan te pakken", aldus Google in een eigen verklaring.

Veel van de codebasis van Google-producten is echter nog in C++ geschreven. Ook andere organisaties werken tegelijkertijd met oudere C++-codebases en Rust. Volgens Lars Bergstrom, bestuursvoorzitter bij de Rust Foundation en directielid bij Google, is het daarom essentieel dat de interoperabiliteit tussen de twee talen verbeterd wordt voor de adoptie van Rust.

Reacties (42)

[downtime]

Wel interessant dat Google doneert aan de Rust foundation hoewel hun eigen Go vaak als concurrent van Rust wordt gezien.

[joost00719]

Is Go niet een compleet andere doelgroep dan Rust?
Ik heb zelf geen ervaring met Go of Rust, maar naar mijn idee was Go bedoeld voor o.a. hogere level applicaties met uitstekende multi-threading support, en Rust meer een vervanging voor C++, en voor wat lower level applicaties bedoeld zoals drivers of juist applicaties waarbij snelheid écht belangrijk is.

[bantoo]

Go was bedoeld als optie voor applicaties waar anders voor Java/C++/C gekozen zou worden binnen Google. Er is zo nu en dan wel iets waar je niet echt lekker uit de voeten kan met een GC en om een of andere reden een eis hebt gekregen dat je geen C++ kan gebruiken, dan komt Rust aanzetten neem ik aan.
Go en Rust hebben inderdaad andere toepassingen maar ze worden allebei voor de taak "servers" gebruikt binnen Google.

[downtime]

Go was bedoeld als optie voor applicaties waar anders voor Java/C++/C gekozen zou worden binnen Google. Er is zo nu en dan wel iets waar je niet echt lekker uit de voeten kan met een GC en om een of andere reden een eis hebt gekregen dat je geen C++ kan gebruiken, dan komt Rust aanzetten neem ik aan.

Nou, Java, C++ en C hebben al verschillende use cases. Voor het bouwen van een OS of drivers kijk je naar C of Rust (beide geen OO en geen GC), voor performance gevoelige applicaties kijk je naar C++ of Go (OO maar geen GC), en als stabiliteit en snelheid van ontwikkeling belangrijker is dan performance dan kijk je naar Java of C# (OO en GC). Maar er is veel grijs gebied.

Maar ik ben geen developer dus mijn kennis van de verschillende talen is oppervlakkig en ik kan er dus ook finaal naast zitten.

[jacobkap]

Je verhaal klopt helemaal. Het enige dingetje is dat Go wel een Garbage Collector heeft.
Voor performance gevoelige applicaties is Rust trouwens ook een uitstekende keus.

[downtime]

Oeps, zie je wel, daar ga ik al de fout in

[Mikke8]

Go maakt ook gebruik van een Garbage Collector!

[Vinxian]

Dat rust geen OOP is ligt maar net aan je definitie van OOP.
De enige vaak genoemde OOP feature die Rust "mist" is inherentance. Maar de 2 belangrijkste onderdelen van inherentence heeft Rust andere elegante oplossingen voor.
Als het gaat om code hergebruiken heeft Rust "default traits". Als het gaat om Polymorphism heeft Rust wederom traits!

En helemaal aangezien inherentance tegenwoordig niet meer in smaak is ten behoeve van andere oplossingen, denk aan composiete objecten met dependency injection en interfaces, vind ik dat je kan stellen dat Rust OOP is.

Edit: spelling

[Reactie gewijzigd door Vinxian op 25 juli 2024 02:35]

[Fatuna]

Voor de volledigheid, Rust is wel OO. Wel anders dan bijvoorbeeld C++ of Java. Zowel Go als Rust werken met OO door compositie ipv overerven (google dat maar ). En hoewel het vroeger zeker waar was dat snelheid van ontwikkeling vooral gewonnen werd door traditionele talen, zijn Go en Rust daar ook goed aan de weg aan het timmeren.

[MocroBorsato]

Goed aan de weg aan het timmeren.... Maar in het geval van Rust mis ik vaak hele "basale" packages/crates die er bij de concurrent wel zijn. Iets als bijvoorbeeld een task queue of een ORM zijn binnen Python en Node.js een stuk beter geregeld en ondersteund

[Gropah]

C++ of Go (OO maar geen GC)

Go heeft zeer zeker wel een GC. Maar het is er wel 1 die een stuk moderner is dan vele andere GCs. Zo draait ie parallel, heeft ie weinig world stops nodig en is ie snel met andere stops.

Go is trouwens ook niet per se de snelste taal. Het is een taal die een goede standaard library heeft voor alles rondom netwerken, en het is een taal die gemaakt is om snel op te pakken (zoals python dat origineel ook had) door de taal klein te houden en er vaak ook maar 1 idiomatic manier is om iets te doen. Daarbij is onderhoud ook relatief makkelijk om te doen door de grote backwards compatability.

Het is in niets echt het beste (behalve wellicht concurrent programming) maar is goed genoeg in veel dingen waardoor het een interessante keuze kan zijn.

[Barsonax]

Wel een dev hier en kan je vertellen dat een taal als C# tegenwoordig qua performance niet meer onderdoet voor Go of C++. Dit veranderd dus ook door de tijd heen en ligt niet vast.

Ligt er natuurlijk wel aan hoe je je code schrijft maar dat is in elke taal zo.

Je kan zelfs AOT doen met C# tegenwoordig al staat dat nog een beetje in de kinderschoenen.

[Reactie gewijzigd door Barsonax op 25 juli 2024 02:35]

[Osiummaster]

De taal maakt in werkelijk heel weinig uit. De efficientie van de algoritmes zijn een stuk belangrijker.

[joost00719]

Python enters the chat...

[Osiummaster]

Python is in vele gevallen sneller dan c++ omdat libraries zoals Numpy geschreven en geoptimaliseerd zijn in c++.

Zet dat tegenover iemand die zijn eigen algoritme gaat verzinnen in c++ dan is de kans groot dat hij slechter in programmeren is dan de numpy devs en een langzamer algoritme verzint.

99% van de executie tijdsduur gaat meestal zitten in minder dan 5% van de code en dit zijn vrijwel altijd loops over arrays.

[Reactie gewijzigd door Osiummaster op 25 juli 2024 02:35]

[Verwijderd]

Dan is Python niet sneller dan C++. Maar wel Numpy sneller dan de meeste zelfgeschreven algoritmes.

[Osiummaster]

Inderdaad maar dat is het punt. In Python is het simpel om geoptimaliseerde algoritmes te implementeren.

De gebruikte algoritmes zijn vrijwel altijd een stuk relevanter dan de gekozen programmeer taal. Sterker nog als je CUDA mappings zoals Pytorch gebruikt kan je in Python snellere code draaien dan in C++.

[Powerblast]

Zo zie je maar dat het ook persoonlijke voorkeur voor een deel is. Vind persoonlijk Python echt een draak van een taal, samen met Javascript. Ik heb nog altijd gewoon de voorkeur voor Java, C, C++, enz.

Rust heb ik een tijdje verkend voor gamedev, maar daar is het eco systeem toch nog niet echt klaar vind ik. Meeste tutorials, guides, voorbeelden zijn ook gewoonweg in C++ of C, waardoor Rust combineren met gamedev leren helemaal niet opschoot .

[rvt1]

… looks and leaves the chat…

[bantoo]

Java C++ en C hebben vaak de zelfde use case. Programmeertalen zijn normaliter voor algemeen gebruik gemaakt, niet taak specifiek. Dit was trouwens geen mening, dit was de interne logica van Google.

[Fatuna]

Java en C komen elkaar niet zo vaak tegen hoor, in ieder geval niet in de afgelopen 10 jaar. C gebruik je als je alle power uit de hardware wilt halen. Java als je je hardware in een elektrisch kacheltje wilt veranderen .

[bantoo]

Ja goh en Go komt uit 2008.

[Fatuna]

Daar heb je gelijk in. Die 10 jaar is misschien wat kort door de bocht, waarschijnlijk is het wel 20 jaar..
Wat ik bedoelde, Java en C++ worden vooral gebruikt voor applicaties (bijvoorbeeld games), C voor drivers, kernels en embedded use cases. Vroegah, werd C ook wel gebruikt voor applicaties (immers het is ouder dan C++ en Java), maar tegenwoordig (hoop ik) niet meer.

[Reactie gewijzigd door Fatuna op 25 juli 2024 02:35]

[bantoo]

Ik ben het helemaal met je eens maar Go is afkomstig uit de Bell Labs school. Mensen op Unix (Linux) zijn nog heel lang op C blijven hangen voor applicaties waar een normale taal een veel betere match was. Initiële externe marketing van Go was ook op die groepen gericht.

[Powerblast]

C is wat mij betreft als je bare metal wil aan spreken of echt alles van performance eruit wilt halen. Wil je echter business apps developen, daar bedank ik toch echt vriendelijk voor om dat in C te gaan doen . Draait dan wel een stukje trager, al is dat ook relatief, maar development gaat zo veel sneller.

[Niosus]

Ja ik zie go eerder als een JS/Node of Python alternatief voor op de server. Je kan makkelijk een servertje draaien dat veel traffic tegelijk aan kan, maar je werkt in een taal waarmee je een stuk zekerder kan zijn van je code (en het is tegelijk een pak performanter out-of-the-box). De memory safety maakt hier weinig verschil, want al die andere talen hebben dat ook al in zekere mate. Rust gaat wat verder, maar dat heeft niet veel toegevoegde waarde als elke request gewoon in zijn eigen geïsoleerde thread draait en niet meer doet dan DB requests voor te kauwen en terug te geven.

Rust is eerder iets voor het OS team. Daar zit je typisch met een berg C/C++ en hier komen ook de gevoelige kwetsbaarheden naar boven die Rust in veel gevallen onmogelijk maakt. Go zou dit ook kunnen doen, maar de unieke features van de taal hebben hier weinig toegevoegde waarde.

Ik denk niet dat er veel overlap te vinden is. Sure je kan alles doen met elke taal, maar je moet toch echt al een heel goede reden hebben om van de standaard niches af te wijken.

[Brent]

Als je kijkt naar Google's C++ style guide, dan zie je een aantal richtlijnen die in Rust verplicht/makkelijker zijn (met ook op mem safety bijv). Google is een grote C++ shop, dus de belangstelling voor Rust snap ik goed.

Fuchsia is bijv al grotendeels in Rust geschreven.

[jaapzb]

Go en Rust hebben inmiddels beide hun eigen niches wel gevonden, er is ruimte zat voor beide talen.

[davekok]

Oh ik dacht dat Go eigenlijk een beetje op zijn retour is. In Kubernetes wereld wordt het nog veel gebruikt en zal voorlopig wel even door gaan. Maar buiten dat het ik de indruk dat het niet meer echt voor nieuwe dingen omarmt werd.

[ChefA]

Go is abosuluut niet op zijn retour, integendeel zelfs.

Bij ons worden momenteel voor veel klanten backend-services herschreven in Go, vooral voor gevallen waar daarvoor Python of Java werd gebruikt. Dit levert in veel gevallen erg grote bespraring op resources op.

[!GN!T!ON]

Wij zijn ook aan het kijken onze applicaties om te zetten van Java naar Go. Vooral omdat Java i.c.m. Kubernetes qua scaling en minimum required resources voor een pod niet echt lekker werken. Wij verwachten hierdoor ook een flinke besparing op resources, maar ook sneller startende en stoppende containers en betere performance

Ik vind het persoonlijk wel jammer dat we intern niet voor Rust hebben gekozen, die memory safety is mij toch een groot goed. Maar bijna de hele developer afdeling wou liever Go.

[Reactie gewijzigd door !GN!T!ON op 25 juli 2024 02:35]

[jabwd]

Go heeft ook memory safety in die zin! alleen is het verschil dus dat dat door de GC komt wat in sommige gevallen problemen kan veroorzaken. Al zal je niet snel tegen die muur oplopen tenzij je op een Discord achtige schaal zit of games maakt.

Zelf zie ik het nog steeds beetje als waar je zin in hebt, de learning curve van Rust is best groot, en daar is Go voor beginners toch prettiger (dus ligt aan wat voor team je hebt bijv.)

Zelf werk ik de laatste tijd veel met Rust, en heb ik nog niet echt goede redenen gehad om met Go te spelen jammer genoeg.

[Keyb]

Ik zit zelf midden in een project met Go en zal het voortaan toch echt proberen te vermijden. Ik ben er echt niet over te spreken. En de developer mentaliteit van Go developers al helemaal niet. Die van "als het niet in de standaard library zit heb je het niet nodig". Over de lelijke manier van foutafhandeling maar niet te spreken.

[mekkieboek]

Grafana is geschreven in Go (en typescript lees ik). Ik vermoed dat Grafana nog wel gebruikt wordt hier en daar

[Wolfos]

Google is gigantisch en gebruikt natuurlijk heel veel programmeertalen.

[Haribo112]

1 miljoen? Dat is voor Google zo'n klein bedrag dat er over vergaderen al de moeite niet is.

[MiesvanderLippe]

Dat is toch wel een klein team developers voor een jaar afhankelijk van waar je ze inkoopt. Dat kan best een flinke impact hebben.

[Frame164]

In Nederland zou het een team van ca. 10 personen zijn. In India 40....
Daar kan je wat mee. Zelfs met een NL team van 10 personen.

[wiseger]

Hoe kom je erbij dat goed gekwalificeerde ontwikkelaars in India je slechts 25K per jaar kosten?

De tarieven die ik ken van TCS, HCL, InfoSys et cetera liggen vele malen hoger.

[johnbetonschaar]

Ik weet niks van de salarissen van ontwikkelaars in India, maar ik weet wel dat de tarieven die je aan TCS, HCL, InfoSys etc betaalt, niet direct representatief zijn voor de salarissen van die ze hun werknemers betalen . Een consultant inhuren hier in Nederland kan ook goed 200 euro per uur kosten maar ik denk niet dat er veel ontwikkelaars zijn die dat ook als salaris uitbetaald krijgen (ik niet in ieder geval ).

[Reactie gewijzigd door johnbetonschaar op 25 juli 2024 02:35]

[markwiering]

Verschillende bedrijven stappen over van C++ naar Rust, vooral omdat Rust minder geheugenfouten veroorzaakt.

Het probleem zit hem niet in de programmeertaal, maar in de programmeur. In C++ kun jij prima dingen gedaan krijgen zonder geheugenfouten. Daar hoef jij geen genie voor te zijn. Als jij gewoon een knappe datastructuur uitdenkt, komt alles goed.

Zo heb ik in C++ een eigen dragerklasse geschreven (dynamische rij) waar jij elementen aan kunt toevoegen, lezen en verwijderen. Onder de motorkap regelt die klasse dat er altijd voldoende ruimte is. Als jij naar een index iets schrijft of probeert te lezen dat niet bestaat, detecteert de klasse dit en sluit die het programma af met de juiste foutmelding.

De kans op "segmentation fault" met deze klasse is precies nul. Alles wordt van tevoren netjes afgevangen. Qua geheugen superveilig, want het kan gewoon niet misgaan (is ook nog nooit gebeurd).

Maar, C++ geeft jou de volle vrijheid om ook foutgevoelige code te schrijven. Daarmee kun jij jouzelf in het nauw zetten. Dat is het mindere aan het verhaal, maar met grote krachten komen grote verantwoordelijkheden.

Rust is gewoon helemaal dichtgespijkerd, keurt heel weinig datastructuren goed en weigert vaak om code te draaien waar nul geheugenfouten in zitten, alleen omdat de validator van Rust niet met 100% zekerheid kan zeggen of die code ook echt waterdicht is.