Bredaas bedrijf brengt Rust naar de gpu - 'C++ is niet snel en niet veilig'

Bredaas bedrijf brengt programmeertaal Rust naar de gpu

Het Bredase bedrijf Traverse Research werkt mee aan het opensourceproject rust-gpu, een port van de programmeertaal Rust naar de gpu. Volgens Jasper Bekkers van het bedrijf zijn bestaande talen voor het ontwikkelen van gpu-engines aan vervanging toe.

Vorige week verscheen rust-gpu op Github. Het doel van dit opensourceproject is ambitieus: het moet van Rust een eersteklas taal en ecosysteem voor gpu-code maken. Initiatiefnemers van het project zijn compiler engineer Ashley Hauck en rendering engineer Jasper Bekkers. Hauck werkt bij Embark Studios, een gamestudio die is opgericht door voormalige DICE-medewerkers. Bekkers is oprichter van Traverse Research uit Breda, een research & development-studio voor games en graphics gerelateerde technologie. We spraken Bekkers over zijn nieuwe project.

C++ en HLSL

"Eigenlijk begon dit verhaal al tien jaar geleden", vertelt Bekkers. "Ik heb in Breda de gameopleiding gedaan, voorheen IGAD aan de NHTV, nu Creative Media and Game Technologies aan de BUAS. Ik ben toen stage gaan lopen bij EA, waar ik ben blijven hangen. Ik heb onder andere aan de Frostbite-engine gewerkt en heb in die periode veel voor videokaarten geprogrammeerd.'Wij schrijven al onze software al in Rust'" Bekkers werkte onder andere mee aan Star Wars: Battlefront, Mirror's Edge en Dragon Age: Inquisition. Het ontwikkelteam van Frostbite gebruikte C++. Wat betreft shadertaal was dat High-Level Shading Language, of HLSL, van Microsoft.

"Die talen zijn kwetsbaar voor bufferoverflows en daardoor onveilig, ze hebben geen package manager, en zijn foutgevoelig. Dat heb ik altijd jammer gevonden. Omdat we met een schone lei begonnen, konden we Rust voor al onze ontwikkelingen gebruiken en hopen we dat te moderniseren", aldus Bekkers. Toen zijn directe leidinggevende Embark Studio's oprichtte en hij zijn eigen bedrijf startte, ontstonden mogelijkheden om de zaken anders aan te pakken.

Het kantoor van Traverse Research in Breda.

"We werken met zes man op kantoor en bouwen onder andere mee aan het techplatform van Embark. Daarnaast bouwen we benchmarks voor hardwarebedrijven. Wij schrijven al onze software al in Rust en zijn daar erg tevreden over. Alle gpu-code zou eigenlijk ook in Rust geschreven moeten worden zodat we een goede integratie tussen gpu en cpu kunnen krijgen en makkelijk code kunnen delen."

Rust is een low-level programmeertaal die is ontwikkeld door Mozilla en deels geïnspireerd is op C. Het is vooral gericht op veiligheid en door afgebakend geheugenbeheer moeten stackoverflows en bufferoverflows tot het verleden gaan behoren. Het is met afstand de meest geliefde programmeertaal, afgaande op de Stack Overflow Developer Survey, en staat daarmee in schril contrast met C++. In augustus werd bekend dat Rust nog dit jaar zijn eigen stichting krijgt en daarmee loskomt van Mozilla. Dit moet duidelijk maken dat het een onafhankelijk project met een eigen juridische identiteit en bankrekening betreft. Het Rust Core Team hoopt zo meer investeringen voor verdere groei te kunnen aantrekken. Inmiddels wordt de programmeertaal door onder andere Discord, Microsoft, Dropbox en Facebook gebruikt.

Meest geliefde ontwikkeltalen, bron: Stack Overflow Developer Survey 2020

Bekkers: "C++ crasht vaak, is niet snel en is niet veilig." Volgens hem kosten bufferoverflows en geheugencorruptie tijdens het programmeren tijd en geld voor bedrijven. Naast de veiligheid zijn er meer 'Gameontwikkelaars zijn huiverig met betrekking tot nieuwe technologie'voordelen aan Rust. Dat heeft bijvoorbeeld een packagessysteem, net als npm, en mogelijkheden om gpu- en cpu-code naadloos te integreren. Maar volledig overstappen op Rust is voor de grote gamebedrijven nog een stap te ver. "Gameontwikkelaars zijn huiverig met betrekking tot nieuwe technologie. Een grote game-engine omvat al snel tien miljoen regels code. De hele industrie draait op C++ en ontwikkelaars zeggen al snel dat ze hier alles mee kunnen. Bovendien gebruiken ze als argument dat zodra je een nieuwe programmeertaal aan zo’n codebase toevoegt, het hele team dan die taal moet kennen."

Opvolger van Rust Like Shading Language

Rust-gpu moet een begin vormen om een modern alternatief te bieden. Of eigenlijk, de voorganger van rust-gpu vormde dat begin: Rust Like Shading Language, of RLSL, een project dat Maik Klein van Embark drie jaar geleden startte. Klein had geen tijd meer voor RLSL, maar werkt nu wel mee aan rust-gpu, dat voortborduurt op zijn project. In totaal werken nu acht personen aan het project en het doel is om een gemeenschap van ontwikkelaars op te bouwen.

Voorlopig bevindt het project zich in een vroege fase. Bij versie 0.1 werken alleen nog het compilen en draaien van erg simpele shaders en het compilen van delen van de Rust Core Library. Bekkers heeft als voorbeeldshader een lucht ontwikkeld. Het project heeft een roadmap met zes levels opgesteld, met als eindstadium 'all the cool kids use shaded rust'. Nu is er nog sprake van het prototype-stadium.

Een voorbeeldshader van lucht die Bekkers heeft ontwikkeld.

Volgens Bekkers moet het Rust-ecosysteem voor gpu's vooral voordelen bieden aan indiegamestudio's. Die zijn nu voor een groot deel afhankelijk van de Unreal Engine of Unity en hebben niet de resources voor eigen inbreng. In zijn visie ontstaat er een modulair platform dat beter schaalt dan het werk aan die engines. "In het ideale geval ontstaat er een community die eigen packages maakt en waarbij iemand zegt ‘ik heb deze vette shader gebouwd’, die anderen dan weer kunnen gebruiken."

Traverse Research merkt dat gameopleidingen alvast meer aandacht beginnen te krijgen voor Rust. "We hebben contact met HBO- en universitaire opleidingen en zij komen naar ons met de vraag 'moeten we al aan de slag met Rust?'. Iedere stagiair die bij ons werkt, wil na twee maanden in ieder geval niet meer terug naar C++."

Reacties (154)

[johnbetonschaar]

Super interessant natuurlijk, en ik denk dat de meeste mensen het er wel over eens zijn dat Rust veel voordelen heeft ten opzichte van C++, maar opmerkingen als "die talen zijn kwetsbaar voor buffer overflows en daardoor onveilig", "C++ crasht vaak, is niet snel en is niet veilig" vind ik toch echt wel heel erg kort door de bocht.

C++ is ook maar 'gewoon een programmeertaal', en C++ zelf crasht natuurlijk niet, als er als iets crasht is dat de code die je er mee schrijft. En ja, met C++ is het makkelijker fouten maken of 'onveilige' code schrijven dan in Rust, maar je kunt je serieus afvragen in welk opzicht dat relevant is voor GPU programming waar hoegenaamd zo goed als geen C++ aan te pas komt buiten misschen wat boilerplate, voor de rest is dat allemaal HLSL/GLSL/Metal SL/etc voor shaders, of CUDA + C voor GPGU. Of zijn er echt mensen die CUDA kernels in C++ schrijven? (het kan wel geloof ik maar ik kan me bijna niet voorstellen wat je er aan hebt).

Goede ondersteuning voor GPU programming in Rust is uiteraard heel welkom maar ik denk dat dat vooral problemen oplost voor mensen die de rest van hun engine ook in Rust willen schrijven en geen zin hebben om voor GPU-code ook nog wat C/C++ binding code plus shaders en/of CUDA mee te linken, niet dat GPU code zelf daar nou echt makkelijker, veiliger of sneller van zal worden.

[PrisonerOfPain]

Ik heb natuurlijk jaren lang zelf in C++ geschreven en wilde daarom juist de overstap maken. Crashes en memory corruption debuggen in C++ is gewoon aan de dagelijkse orde, en kost grote bedrijven enorm veel geld. Volgens Microsoft zijn buffer overflows een van de meest voorkomende CVEs, dat gaat dus nog verder dan enkel ontwikkelkosten.

Ik heb zelf ook redelijk professioneel CUDA geschreven, en het is heerlijk om op de CPU en de GPU precies dezelfde code te kunnen draaien en die te kunnen delen. Maar nog steeds ben je, net als in HLSL, zelf je synchronisatie primitives aan het toevoegen (groupsync en deregelijke) en ben je zelf aan het zorgen dat je geen memory corruption hebt door bijvoorbeeld data op de verkeerde plek in een buffer te gooien.

Dit is de reden dat we naar Rust zijn gaan kijken, initieel voor de CPU maar we denken dat het mogelijk maken van ideeen lijkende op Fearless Concurrency en Safe by Default we GPUs een stuk toegankelijker kunnen maken.

[atlaste]

Ik doe al ongeveer 20 jaar professioneel c++ nu, heb talloze mensen geholpen op irc als ops in een c++ channel en heb een vriend in de standard committee.

Het grote probleem van c++ is dat het op grote schaal als c wordt gebruikt. Ik heb projecten gedaan van enkele honderdduizenden regels code, die in 1 keer werkten en jarenlang hebben gedraaid. Als je het goed gebruikt, kan je gigantisch veel compile time controleren, anders dan bij de meeste andere talen. De ellende is alleen dat je dan wel goed moet weten hoe de details zoals fsinae, static checks, overload resolution en templates precies werken...

Als crashes aan de orde van de dag zijn, heb je meestal niet de RAII op orde.

Performance ben ik wat minder positief over. De grootste performance drain van alle talen is memory access en managenent. Wij hebben zelf een moderne generational garbage collector gemaakt, en in veel gevallen outperformed deze constructs die alternatieve structuren zoals shared_ptr en zelfs unique_ptr. Het punt wat veel mensen niet beseffen is dat een generational gc ook direct memory fragmentation en reordering doet, met weinig overhead, waardoor je meer cache hits "kado" krijgt. In het beste geval is het zelfs niet veel trager dan een memory arena... Minpunt is dat het ding op ieder moment kan langskomen. De GC draait overigens zelf in C++... dus dan is het gefixt toch?

Ja, het draait, maar omdat de taal niet fundamenteel gebouwd is op een goed memory model, krijg je een rare mix van verschillende types pointers. Geen feest om in het echt te gebruiken... Maar je hebt zeker de optie...

In all fairness, dat is dus allemaal niet ideaal in een professionele omgeving... Meestal zitten daar immers ook een hoop mensen die niet de ins en outs weten.

Kortom: C++ moet je denk ik gewoon zien als een soort "high level assembler". Als je goed je best doet, kan je er heel veel snelheid en controle uit persen. De cost is echter dat je verdomd goed moet weten van de details. Een meer praktisch compromis van "redelijk veel performance tegen een veel eenvoudiger model" is dus zeker gewenst en verstandig. Dit is volgens mij de kracht van moderne talen zoals Rust.

[Xieoxer]

Helemaal met je eens! Ik werk voor een bedrijf dat eigen live broadcasting software maakt. Wij gebruiken voor het playout gedeelte alleen C++, wegens performance. Wij moeten binnen 40ms een complete frame produceerden dat audio, video, logo’s, en subtitles bevat. Als
Je 25fps moet halen. Dit gaat je niet lukken met talen die hun eigen memory management systeem gebruiken. Wij willen enorme controle hebben op hoe de data wordt opgeslagen in de heap. Door verstandig te programmeren kun je enorm veel performance met C++ halen. Tuurlijk kost dit veel extra ontwikkeling tijd, omdat je alles zelf moet gaan regelen. Maar ik dat is denk ik weer de kracht achter de taal, dat je meer controle hebt hoe je data wordt ingezet en dat je alles zelf moet regelen. Tevens ben ik ook niet mee eens dat C++ vaak crasht, dat hangt echt af hoe je software inzet en de context er om heen. Onze software draait 24/7 non stop, en wij hebben nooit last van vastlopers. We testen onze software enorm goed voordat wij in productie brengen.

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

[BikkelZ]

Het moet met Rust ook gewoon mogelijk zijn het zelfde soort performance te krijgen, dus niet alleen snel (want dat kan met Java ook) maar ook voorspelbaar, dus zonder stop-the-world garbage collection op momenten die je die zelf onder controle hebt.

Vrijwel alle code die ik gelezen heb die werkt met dat soort real-time constraints waarbij je een frame een vaste lengte heeft is in C++ geschreven, bijvoorbeeld de WebRTC implementatie of VST plug-ins (voor audio software zoals Cubase).

Het is uitstekend geschikt daar voor omdat je ook goede controle hebt over de input van de meeste functies, bijvoorbeeld de tekststream en de videostream die je gaat mergen. Er zitten daar ook weinig mensen naar te kijken van "hoe kan ik dat hacken" hoewel het hijacken van een live videostream wel interessante toepassingen kan hebben

Waar het fout gaat met talen zoals C++ is dat op het moment dat je een interessant genoeg target bent en je zet jezelf open voor user input dat er dan op allerlei manieren exceptions te triggeren zijn. Probeer je maar eens voor te stellen hoe veel je kunt uithalen alleen al door gekke dingen met URL's te doen. De meeste van dat soort problemen zijn simpelweg te voorkomen door Rust te gebruiken.

Ook is het feit dat jij code kunt schrijven in C++ die niet crasht geen testament voor het feit dat het makkelijk is om foutloze C++ code te schrijven. Er zijn mensen die codebases van 200.000 regels Javascript beheren. Dat wil niet zeggen dat mijn stelling dat geen enkel programma langer dan 500 regels niet in Javascript geschreven zou moeten worden niet waar is

[johnbetonschaar]

Oh ik zal ook zeker niet ontkennen dat Rust in de meeste gevallen absoluut een 'betere' taal is dan C++ (hoewel ik zelf eigenlijk 0 praktijkervaring heb in Rust, maar ik zie zelf natuurlijk ook wel de problemen van C++). Maar je kunt volgens mij echt niet zeggen dat 'C++ niet snel is', en tegenwoordig ook niet echt meer dat het per definitie 'onveilig' is of 'vaak crasht' (ik neem maar even aan dat daarmee de C++ code die je schrijft wordt bedoeld en niet de C++ toolchain ofzo ). Een goede C++11/14/17/20 programmeur schrijft toch tegenwoordig geen enge loopjes met side effects en new/delete met naked pointers en alle die dingen meer?

Maar nog steeds ben je, net als in HLSL, zelf je synchronisatie primitives aan het toevoegen (groupsync en deregelijke) en ben je zelf aan het zorgen dat je geen memory corruption hebt door bijvoorbeeld data op de verkeerde plek in een buffer te gooien

Ik ben heel benieuwd hoe rust-gpu dit makkelijker/toegankelijker wil gaan maken dan, wat memory safety kan ik me er nog wel iets bij voorstellen, maar ik heb zelf altijd de indruk gehad dat de moeilijkheid bij GPU programming hem eigenlijk meer in shaders zelf zit, of in het geval van GPGPU hoe je het voor elkaar krijgt om je algoritme uberhaupt op de GPU hardware te mappen. Voor synchronisatie/scheduling etc. zit je toch vast aan wat CUDA je kan bieden, of is de bedoeling dat rust-gpu een volwaardig CUDA alternatief moet worden (in dat geval heb je nog een hoop werk voor je )?

Ik ga het in de gaten houden hoor

[Reactie gewijzigd door johnbetonschaar op 22 juli 2024 20:23]

[GenGF]

Ik zie nog regelmatig beginnende professionals K&R-stijl C schrijven, neem aan dat er ook nog zat oude-stijl C++ de wereld in geslingerd wordt.

[MSalters]

Het zal ongetwijfeld voorkomen - @laserve hierboven noemde het al. Maar C is toch een ander verhaal. Nadat C++ ontstond, is de ontwikkeling van C vrijwel stil komen te staan. Het verschil tussen C99 en C11 is vooral theoretisch, het verschil tussen C++98 en C++11 is levensgroot. (Wat ook al weer 4 versies geleden is).

Wat overigens wel een issue is, is code uit India. Om één of andere reden leren ze daar nog programmeren met Turbo-C++ uit 1995. Maar goed, dat is het soort kwaliteit wat je bij offshoring mag verwachten.

[Elijan9]

C99 was een behoorlijke verbetering op de C standaard en C11 op zich ook (Unicode support, threading en atomic types), maar in C11 zijn óók diverse verbeteringen afgezwakt om Microsoft tegemoet te komen. Maar zelf met deze aanpassingen ziet het er niet naar uit dat Microsoft van plan is actief aan het C gedeelte van hun compiler te werken en zal volledige C11/C18 ondersteuning waarschijnlijk nooit toegevoegd worden. Mede daardoor staat de evolutie van de taal C zo goed als stil, de taal was juist bedoelt om software te kunnen schrijven die op zo veel mogelijk platformen zou kunnen compileren en dat heeft Microsoft effectief de nek om gedraait als het gaat om C99 en C11/C18.

[MSalters]

Dit legt de schuld wel vrij hard neer bij Microsoft.

Microsoft heeft erop gewezen dat Windows geen voorkeur heeft voor C implementaties. In tegenstelling tot Linux, waar libc een onderdeel van het OS is, is de C runtime in Windows een zaak van de applicatie. Desondanks zijn er geen serieuze aanbieders van C99 en C11 compilers voor Windows.

Waarom is dat zo? Ik denk dat een belangrijke verklaring dus precies het gebrek aan innovatie in C99 en C11 is. Een commerciele C11 compiler moet de concurrentie aan met de C90 modus van MSVC, en de meerwaarde die C11 aan zo'n compiler biedt is blijkbaar te beperkt. De andere factor is mingw-64. Niet perfect, wel gratis.

[Verwijderd]

Na jaren C# ben ik al een jaartje weer terug bij C++ (en CUDA) en ik kon het eigenlijk helemaal opnieuw gaan leren.

De 'enge loopjes' waar @johnbetonschaar het over heeft staan eigenlijk alleen maar in de device code. En naked pointers gebruik ik feitelijk nooit. Daar waar ik voor CUDA met naked pointers zou moeten werken zijn zo veel mogelijk goed geteste wrappers gemaakt, zodat ik daar niet meer mee te maken heb.

Eigenlijk alleen nog maar memory debuggen in kernel code, in host code ben ik in het afgelopen jaar tegen geen enkele memory bug aangelopen. En ja, dat veraste me zeer!

Overigens wordt als voordeel van rust veel genoemd expliciet moeten aangeven dat een variabele mutable is. Veel van dat voordeel kan je in C++ ook krijgen door goed gebruik van const/constexpr en vooral heet terughoudend te zijn met const_cast.

Een andere die ik tegen kwam was expliciete types voor bijvoorbeeld 16,32 en 64 bit ints. Dat is in C++11 al opgelost met <cstdint>.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 20:23]

[djwice]

Waar ik al een tijdje mee worstel (jaartje of 4 tot 5) is, hoe kun je serverless GPU functies maken. Zeg maar een AWS Lambda (Google/Azure Functions) voor GPU code die op een GPU draait. Waarbij je er voor zorgt dat de instance die er na draait, niet de data van de vorige processen of andere processen die draaien op andere cores kan lezen.

En dat op een manier dat je de data snel beschikbaar hebt en de code heel snel kan draaien over meerdere cores.

Maar wellicht met de PCI 4.0 bus dat dit makkelijker opgelost kan worden, omdat de GPU nu zonder tussenkomst van CPU bij de storage kan. Dan nog is legen en isoleren van geheugen en cores kan een uitdaging.

Een serverless functie laad wanneer hij nodig is, start, laad data in, voert uit en wordt dan weer verwijderd uit het geheugen. Typisch een levensduur van 5ms tot enkele minuten maximaal, vaak binnen 100ms zijn ze gestopt, start tijd is maximaal 5 tot 25ms afhankelijk van de complexiteit van de ongecompliceerde code.

[Reactie gewijzigd door djwice op 22 juli 2024 20:23]

[bloq]

Ik weet dat er machine learning nodes te draaien zijn in docker-containers, en docker containers worden ook in sommige faas implementaties toegepast. Gpu kan aangesproken worden met wat foefjes door de docker container. Misschien dat je iets in die hoek kunt vinden?

[djwice]

Ik zal eens kijken, het gaat er eigenlijk om dat ik een container wil die geen CPU gebruikt naast de GPU.
Bedankt voor de tip, ik ga je tip verder onderzoeken, als je linkjes hebt naar die foefjes hoor ik het graag

[Zoijar]

Crashes en memory corruption debuggen in C++ is gewoon aan de dagelijkse orde, en kost grote bedrijven enorm veel geld.

Nooit last van, doe het zelden tot nooit memory corruption debuggen. Het verschil hier is gewoon dat je het from-scratch schrijft. Als je dat in C++ of een andere taal doet met dezelfde aandacht heb je ook nooit memory corruption.

[Lamer_Deluxe]

Precies dit. Ik gebruikte bijvoorbeeld ook geen smart pointers, maar gewoon netjes je geheugen weer vrijgeven op de juiste momenten. De applicatie die ik schreef (from scratch, inclusief een custom UI framework) was verreweg de meest uitgebreide van het bedrijf en ook verreweg de meest stabiele. De testers vertelden mij dat het de enige applicatie was waar ze niet bang voor waren, omdat er geen vreemde dingen mee gebeurde.

Overigens is C++ zelf helemaal niet langzaam natuurlijk, het ligt helemaal aan hoe je programmeert. Het zit behoorlijk dicht op assembly.

Grappig overigens dat assembly zo weinig geliefd is, ik vermoed dat dat komt door de onelegante architectuur van Intel processoren. Ik vond 68K assembly altijd erg fijn programmeren, ook de PowerPC architectuur is mooi. Zelfs de 6502 en Z80 zijn leuk om in assembly te programmeren. Je moet natuurlijk niet een heel uitgebreid project, of een project met veel lastige formules in assembly gaan schrijven.

[Vlad86]

Als je zegt "C++ is niet snel", meesten denken meteen aan de snelheid hoe de gecompileerde code wordt uitgevoerd (IPC)... kan aan ene kant niet kwalijk nemen, want de nerd in mij denkt daar ook meteen aan. Maar als je wat breder denk, wat volgens mij door een aantal wordt gemist is de "production snelheid" vs "IPC". Juist de combinatie van beiden is wat het interessant maakt.

Dus als je fouten in je code maakt, wat bij C en C++ heel makkelijk is, is je production snelheid traag zelfs door fouten je IPC kan schaden. Denk bijvoorbeeld aan een niet efficiente thread synchronization.

Of denk aan al het moeite dat je moet doen om je HLSL moet complimenteren met C++.. en de fouten dat daar kunnen ontstaan door de complexiteit.

Iig, ik vind dit een mooi ontwikkeling en ben heel erg benieuwd hoever dit kan schoppen!

[kodak]

Crashes en memory corruption debuggen in C++ is gewoon aan de dagelijkse orde

Maar dat ligt niet zomaar aan de taal. De taal kan toegepast worden zonder dat je last van dit soort problemen hebt, maar dat hangt dus ook af van hoe je het toepast. Dit soort opmerkingen van over een taal toont eerder aan dat iemand niet helemaal lijkt te hebben begrepen beveiligingsproblemen en andere kostbare fouten net zo goed door de ontwikkelaars komen die moeite hebben om de taal te beheersen. Dat het met Rust of andere talen makkelijker kan zijn om de fouten te voorkomen dat is goed mogelijk. Maar om het volledig op de taal te schuiven is te kort door de bocht.

[PrisonerOfPain]

Ik heb in teams gewerkt van 100-200+ C++ developers, natuurlijk zitten daar mensen tussen die niet alle nuances van de taal en de gebouwde systemen begrijpen. Helemaal niet erg, kan gebeuren, maar het hoort er echt wel bij.

[gnik]

Crashes en memory corruption debuggen in C++ is gewoon aan de dagelijkse orde

Ik zie wel meer comments langs komen over debuggen en dat het zoveel tijd kost. En ook de vele craches wordt regelmatig genoemd. Ik herken dit beeld echter totaal niet. Zelf spendeer ik misschien 1 uur in de twee weken aan debuggen. En ik denk dat dat verschil ligt aan een aantal factoren

* alle code moet gereviewed worden, waarbij er een focus is op: defensive programming, good practises, simpel ontwerp en simpele code, geen moeilijke template constructies die door bijna niemand te snappen zijn.
* lees/begrijp je code, voordat je gaat debuggen of door log bestanden grasduinen. Als je code 'simpel' is kan je het ook beter en sneller snappen. Je ziet dan ook meestal wel waar het fout gaat of kan gaan.
* schrijf veel unit tests, ook voor elke bug zou je een unit/regressie test moeten schrijven
* junioren kunnen gewoon niet goed programmeren en hebben initieel veel begeleiding nodig. Geef ze de tijd om via een aantal iteraties van een eerste ontwerp/uitwerking naar een betere oplossing te komen.
* sommige mensen zullen het nooit leren om 'goede' code te schrijven en in plaats van dat te negeren of er eindeloos energie in blijven steken, moeten je zulke mensen los laten.

[Pep7777]

Ik zelf heb geen eigen ervaring met rust wel heel veel met C++ (vanaf 1995 tot nu C++20 toe).
Weet wel dat rust wat "meta" informatie aan de code mee kan geven die het eea wat meer begrenst.

Maar dat C++ vaker crasht ben ik het niet zomaar mee eens.
De "oude" C++ was inderdaad opletten met pointers. Maar vanaf C++11 is dat wel heel erg verbeterd met de komst van unique pointers en references. Met STL en algorithms hoeven buffer overruns ook geen probleem meer te zijn.

Wat uiteindelijk blijft gelden is : gebruik de programmeer taal die het makkelijkste past bij het probleem wat je aan het oplossen bent. En ja ik heb ook wel eens directX vanuit C# aangestuurd was ook niet moeilijk.
Dus zonder rust code te zien.. geen idee hoe makkelijk en/of veilig het is

[diondokter]

Toen ik ben overgestapt van C++ naar Rust is de hoeveelheid tijd dat ik kwijt ben aan debuggen drastisch omlaag gegaan. Het verschil tussen de twee talen:

Een goede C++ programmeur weet wat die niet moet doen.
Een goede Rust programmeur weet wat die wel kan doen.

[Wulfklaue]

> Toen ik ben overgestapt van C++ naar Rust is de hoeveelheid tijd dat ik kwijt ben aan debuggen drastisch omlaag gegaan.

Wat eigenlijk niets te maken heeft met de taal maar met de compiler en de (uitstekende) ingebouwde checker. C++ kan ook dezelfde niveau van taal checker actief hebben maar er is niemand dat zo een mammoet project wilt aangaan, zeker aangezien de hoeveelheid oudere syntax dat nog in de taal zit.

Het is altijd makkelijk iets vanaf nul te beginnen met een betere basis, meer ervaring van wat je wilt vermijden en minder syntax, en daarop verder te bouwen. Dat gaat niet enkel op voor talen maar ook voor veel software, waar als iemand het herschrijft, dat het een hoge kans heeft een betere basis te hebben, dan iets waar men al 40 jaar aan geprutst heeft.

En om eerlijk te zijn, Rust is enorm de C++ richt aan het uitgaan. Toen ik Rust aanleerde een paar jaar geleden en nu de code aankijk zie ik het spook van C++ langzaam opduiken naar maten je meer en meer een mix van beginners en "experten" dat hun code graag geavanceerd ( = *kuch* onleesbaar ) schrijven.

Combineer dat met de taal dat constant uitbreid met iedere release. Iedereen wilt hun feature en spullen dat C++ aankan, in Rust maar realiseren niet dat ze eigenlijk enorm de C++ route aangaan. Ik durf er niets aan te denken wat de taal zal zijn in 5 of 10 jaar van nu, als men niet leert van de issues van C++.

> Toen ik ben overgestapt van PHP naar Go is de hoeveelheid tijd dat ik kwijt ben aan debuggen drastisch omlaag gegaan.

Grappig genoeg kan ik hetzelfde zeggen over Go. Niemand dat omschakelt naar een andere taal, om stappen terug te zetten in de tijd, nietwaar?

> Een goede C++ programmeur weet wat die niet moet doen.
> Een goede Rust programmeur weet wat die wel kan doen.

Sorry maar dit uitspraak is enorm ... Zo lang je mooi kleurt in de lijntjes in beide talen, zal je geen problemen hebben, het is eenmaal dat je buiten te lijntjes gaat en daar beschermt Rust je ook niet. Je kan jezelf in Rust even goed verbranden met unsafe als je kan met C++.

[diondokter]

Je kan jezelf in Rust even goed verbranden met unsafe als je kan met C++.

Klopt! Maar omdat het een opt-out is, is de default dus safe.

Het gaat me vooral om de tips die je krijgt om betere C++ te schijven.
Vaak zijn de defaults niet goed of je moet bewust kiezen voor een betere optie.

• Gebruik geen raw pointers, maar smart pointers.
• Gebruik geen array, maar std::Array
• Gebruik geen normale variabelen, maak alles zo veel mogelijk const
• Gebruik geen C casts, maar static_cast
• Oh ja, gebruik dynamic_cast wanneer static_cast niet mag
• ints kunnen van grootte verschillen op verschillende platformen, gebruik dus int32_t

Dit zijn allemaal goede tips, maar dat het nodig is om dit te weten om goede code te schrijven is IMO een slecht iets.

Vandaar dat ik zeg dat je bij C++ meer hebt aan de kennis over wat je niet moet doen.
Dit compileert bijvoorbeeld zonder warnings: https://godbolt.org/z/Y38vKc
Antwoord op casten is een C-style cast: https://stackoverflow.com...rt-char-to-int-in-c-and-c

[aldieaccounts]

Oh ja, gebruik dynamic_cast wanneer static_cast niet mag

Tsja, als je dit soort 'tips' nodig hebt dan ken je de taal natuurlijk gewoon niet echt. Dan weet je wel zeker dat je code ook een rommeltje wordt. Je moet wel *weten* wat dynamic_cast en static_cast doen, natuurlijk.

maar goed, het klopt zeker dat C++ niet de meest overzichtelijke taal is. Rust is daarin (nog) beter. Hoewel ik wel eens wil zien hoe de standaard van 'rust2030' er uit gaat zien .

[Olaf van der Spek]

C++ kan ook dezelfde niveau van taal checker actief hebben maar er is niemand dat zo een mammoet project wilt aangaan, zeker aangezien de hoeveelheid oudere syntax dat nog in de taal zit.

https://en.wikipedia.org/wiki/AddressSanitizer

[laserve]

Helemaal mee eens. Eigenlijk al sinds de 98 standaard is C++ al stabiel geworden met de STL bijvoorbeeld. Maar naar wat ik zag was er heel conservatief nog steeds pointers gebruikt werden en dynamisch geheugen en die STL was allemaal maar niks. C++ bleef het C++ van 1985-1998 nog jarenlang.

Sterker nog, in 2017 ben ik aan een project gaan werken nog helemaal pre-98 stijl. 1 andere engineer eraan die zei C++ te kennen maar niet eens wist dat je objecten op de stack kon alloceren, laat staan copy constructors operator= etc. Iedere attempt om C++98 of C++14 code te schrijven werd afgekapt. Zelfs std::vector werd niet geapprecieerd, dat moesten char pointers zijn.

Ik denk dat het niets met techniek te maken heeft, meer een verouderd imago probleem wat alleen met goed leiderschap nog op te lossen is.

[MSalters]

Wat je daar ziet is dat de vraag naar C++ developers zo hoog is, dat zelfs dit soort developers nog een baan kan vinden. Dat is dan wel weer bij bedrijven die zo fout-zuinig zijn dat ze deze developers al 20 jaar lang niet op een bijscholingscursus hebben gestuurd.

[THETCR]

Je hebt helemaal gelijk.

Het probleem met C++ is niet de taal zelf, maar hoe er in wordt geschreven. Het is niet veilig omdat mensen er zelf vaak spaghetti van maken en als het crasht heb je het toch echt zelf fout gedaan. Er zijn genoeg benchmarks te vinden waarbij het overduidelijk is dat met de komst van versie 11, 14 en uiteindelijk 17 de taal een stuk sneller is dan de meeste OOP talen.

[Xander2]

De compilers zijn niet snel

[Immutable]

Denk dat de Rust compiler best snel is, het moet veel meer taken doen dan een C++ compiler. Daarom duurt het wat langer. Gelukkig krijg je daar echt heel veel voor terug.
Heel veel mensen snappen niet dat die extra compileertijd op lange termijn heel veel tijd scheelt. En dan nog, even investeren in een rappe AMD processor en je verkort de tijd. Heb je onder de streep helemaal veel development tijd gewonnen. Al zal de Rust compiler nooit sneller zijn dan die van C++. Die doet gewoon veel minder taken.

[Verwijderd]

Had hij nu gezegd "Rust kan even snel zijn als C++", dan had ik hem serieus genomen. Het is inderdaad perfect haalbaar een programmeertaal en compiler te bedenken die identieke binaries voor elkaar krijgt. Compile het met clang en je hergebruikt zelfs een groot deel van de compiler wat dat betreft.

Maar nu hij zei "C++ is niet snel", is hij meteen de zoveelste die onzin komt verkopen. Per direct.

Zever in pakskes jongen. Bewijs het maar eens. Rust gaat niet sneller zijn. Al was het maar dat er minder veel en minder goede compilers zijn voor Rust. Al kan dat in de toekomst veranderen, is dat nu niet het geval.

Dat C++ niet veilig is, ligt aan de ontwikkelaar en de libraries. Niet aan de taal. Dat Rust veiliger kan zijn ligt aan haar libraries.

C++ crashed vaak zou enkel maar kunnen betekenen dat de compiler vaak crashed. Want of C++ programma's vaak crashen ligt aan de programmeur. Niet aan C++.

Het is nog maar de vraag of Rust er veel aan zal veranderen. De belofte van die ene programmeertaal die alles zal oplossen hoor ik al 25 jaar. Altijd al nonsense geweest. Keer op keer op keer op keer. Vooral wanneer flupperdepup ons kwam vertellen dat X is het nieuwe goede want wij hebben iets met X gedaan en wij dit en wij dat.

Wij van WC eend zeggen. Sure dude. Whatever.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 20:23]

[GertMenkel]

Ik ben het in grote lijnen met je eens, maar:

Dat Rust veiliger kan zijn ligt aan haar libraries.

Dat is gewoon onjuist. Rust is veiliger door beperkingen die de taal aan de programmeur oplegt. Je kunt er omheen werken door bijvoorbeeld unsafe code te schrijven, maar je moet expliciet de veiligheid uitzetten in plaats van andersom. Dat brengt zowel voordelen (geen buffer overflows, exploitbare code, etc.) als nadelen (niet alle abstracties zijn zero-cost, compile tijd is veel hoger, sommige dingen als bomen zijn amper of niet uit te voeren).

Rust is geen programmeertaal die alles op kan lossen, maar ik kan in het gameveld wel zien dat het goede verbeteringen levert.

C en C++ zijn nog steeds de beste taal voor veel systeemprogrammeren waar je handmatig met geheugen werkt en veel GUI libraries gaan ervan uit dat je pointers kan gebruiken dus daar zijn het ook uitstekende talen voor. Voor simpelere dingen als webapplicaties en programma's van beperkte algoritmische complexiteit zijn talen als C#, Java, Python en noem maar op een stuk bruikbaarder omdat de programmeur zich niet bezig hoeft te houden met geheugenoperaties (met als nadeel dat je dan een garbage collector moet draaien).

Rust zit er een beetje tussenin, en zo denk ik ook dat veel games er tussenin zitten. Er is wel de eis dat de code hoge performance heeft, maar toch is er weinig interactie nodig met het besturingssysteem en de directe drivers (dat kan door middel van abstractielagen). In dat veld en een paar andere (denk aan systeemsoftware zonder GUI die lastige taken uitvoert, of IoT-spul waarvan je veiligheid het liefste helemaal top wil hebben) denk ik dat Rust een mooie toevoeging kan zijn aan het arsenaal van een programmeur.

Rust zal geen C vervangen en een hele hoop libraries (COM+ bijvoorbeeld) zullen ook C++ nog wel in dagelijks gebruik houden.

Ik denk overigens wel dat programma's geschreven in C++ daadwerkelijk meer en erger crashen dan programma's geschreven in Rust. Dat komt niet omdat C++ inherent gevaarlijk is, maar meer omdat het de programmeur zoveel vrijheden geeft en lang niet iedere programmeur daarmee om kan gaan. Je ziet in surveys die bijvoorbeeld binnen Microsoft gebruikt worden dat veel crashes en kwetsbaarheden komen door fouten die je kan maken vanwege die vrijheid. Je moet er echt goed achteraan zitten met unit tests + valgrind + cppcheck wil je alle memory issues voorkomen, en die extra moeite wil nog wel eens achterwege worden gelaten als je klant volgende maand een deadline heeft.

Aan de andere kant is code schrijven in Rust moeilijker dan code schrijven in C++, dus die veiligheid kost je wel gewoon ontwikkeltijd. Bepaalde dingen, zoals geoptimaliseerde algoritmes met pointers, kun je gewoon niet even uittikken in Rust, daar moet je omwegen voor gebruiken.

[Verwijderd]

Jouw reactie is dan ook heel wat genuanceerder dan "C++ is niet snel en niet veilig". Op jouw reactie reageerde ik niet.

Natuurlijk heeft Rust bestaansrecht. Maar dat bestaansrecht is niet om C++ te challengen op performance. Bovendien zijn er best wel wat C++ frameworks en libraries te vinden die de programmeur ook aan banden legt.

Wat unsafe code-blocks betreft is dat ook weinig nieuws onder de zon. Dat deed C# ook al zo. En zoals je zelf ook al terecht opmerkt komen die beperkingen altijd met performance-kosten. Zeg maar dat een bitmap afwandelen d.m.v. een ptr++ drie keer te doen (tot aan de rowStride om het einde van de lijn te weten en een keer voor R, G en voor B ) altijd sneller zal zijn dan een C# 'Bitmap' te gebruiken. De eerste techniek mits fout gedaan veroorzaakt een bufferoverflow. Vaak een exploitable. De tweede techniek een Exception. Twee keer raden wat vrijwel alle (professionele) image manipulation softwares doen (hint, hint, het eerste - enfin, de meeste hebben dit achter een library zitten zoals Gegl bij GIMP, en meestal wordt er niet met RGB gewerkt en en en maar dat is hier het punt niet).

Wat hogere programmeertaal betreft is het ook niets nieuw. D als programmeertaal is ook higher level en leunt iets dichter aan bij de C# concepten (interfaces, design by contract, etc). Maar belooft toch gelijkaardige performance mogelijkheden aan C++ (D maakt het mogelijk de GC uit te schakelen, d.i. moeilijker in C#).

Waar ik een allergie aan heb zijn jongens die ons komen vertellen dat X beter is dan Y want en dan een opsomming maken van net die dingen waar Y eigenlijk hét beste wereldwijd in is. X kan best beter zijn dan Y in dat veld. Maar dan mag X dat wel eens bewijzen ook dan. Dat heeft X voor de waarde X = 'Rust', voor de lijst die deze jongen opsomt, nog nooit gedaan waar Y is de waarde Y = 'C++'. Jamais. Nog nooit. Ook deze jongen doet dat niet.

Maar jongetjes die komen vertellen over X horen we iedere week wel ergens (en ik dit al 25 jaar aan een stuk). So what jongetjes. Prove it. Or get off my lawn.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 20:23]

[freaq]

De vraag is hier hebben we het over execution performance, of speed of development.

En het lijkt er op dat jasper hier doelt op development speed, al is Rust ook erg snel in execution.

Snellere dev times waar mensen niet continue in stack traces hoeven te duiken zijn natuurlijk ook veel waard, en als performance dan grofweg gelijkwaardig is, betekent dat dat men ofwel meer kan doen of langer kan optimaliseren.

Ps stop stealing my name

[Reactie gewijzigd door freaq op 22 juli 2024 20:23]

[Verwijderd]

Ps stop stealing my name

Ik was eerst :-)

[temp00]

Ik ben zelf geen programmeur (systeembeheerder) en ik kan je frustratie deels begrijpen maar ergens moet je met dit soort 'jongetjes' (beetje denigrerende term imo) ook wel blij zijn. Ooit was er namelijk ook zo'n 'jongetje' heel enthousiast over C++ en dat dit soort mensen bestaat draagt alleen maar bij aan adoptie en de nooit stoppende evolutie van (nieuwe) programmeertalen. Het zorgt dat mensen scherp en creatief blijven en kan leiden tot nieuwe inzichten. Het moet allemaal wel een beetje onderbouwd zijn, dat ben ik met je eens maar aan de andere kant, wees blij dat er enthousiastelingen zoals deze persoon zijn. Anders zou het allemaal maar zo'n saai, vastgeroest zooitje zijn

[Jeanpaul145]

Het bestaansrecht van Rust is C++ challengen op basis van safety.
Het is tevens Javascript challengen in Webland, doordat het makkelijk naar WASM kan worden gecompileerd, evenals C challengen in de embedded space.

Daarnaast biedt het een unieke mix van features:
* type and memory safety zonder runtime GC
* de type safety is van een vergelijkbaar niveau als Haskell
* proper syntactic macros. Geen preprocessor crap meer.
* in het zeldzame geval dat je een debugger nodig hebt ben je er bijna altijd veel sneller achter wat de root issue is
* geen inheritance = geen inheritance problemen. Dag diep geneste class hierarchies 🤭
* heel prettige package management in de vorm van Cargo
* je moet aardig wat moeite doen om een segfault in Rust te veroorzaken. Tot het punt zelfs dat als dat gebeurt, het aardig zeker is dat het met opzet is gedaan
* if it compiles, generally it works as intended
* geen data races, met dank aan borrowck
* de taal kan zonder veel moeite, in 1 project, webserver taken en embedded taken op zich nemen. Met andere woorden, dit kan taken aan die anders over 2 of meer talen zou moeten worden verspreid (want wie is er nou gek genoeg om een web server in C/C++ te schrijven?)

Er zullen vast meer zijn, maar dat is het lijstje dat op basis van mijn ervaringen boven kwam drijven.

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

[djwice]

Nu gratis Delphi op CD-ROM bij jouw geliefde computertijdschrift

En volgens mij kun je in elke taal langzame code schrijven
En vaak hoe dichter de taal bij de core-instructies zit, hoe langer het schrijven van complexe software duurt.

Rust 4 GPUs -klinkt wel als een project dat funding zou kunnen krijgen, het lijkt me dan wel slim om samen te werken met Mozilla, NVidia en AMD en Microsoft (Visual Studio Code + Windows en Azure optimalisaties, programmeertaal marketing).
En wellicht mooie praktijk challance door delen van bestaande software - blender ofzo - te verbeteren in de nieuwe taal. Dan zie je direct waar je tegen aan loopt in de praktijk. Maar een goede taal ontwerpen is met name ook heel goed denkwerk verrichten

Ooit kregen eerste jaar IT studenten aan de UNI een vak; bouw je eigen OS in assembler, dan een programmeertaal met compiler en dan een werkend stuk software. Er komt veel bij kijken en het is niet voor iedereen triviaal.

[Reactie gewijzigd door djwice op 22 juli 2024 20:23]

[MeMoRy]

En volgens mij kun je in elke taal langzame code schrijven

Dat is toch ook de truc? En paar "performance loops" in de code, die je dan later eruit kan halen en als "performance verbeteringen" kan verkopen.

[djwice]

LOL

# TODO : REMOVE TO INCREASE PERFORMANCE

# TODO : ADD TIMER LOOP WHEN BUDGET DECREASE IS PENDING

[Reactie gewijzigd door djwice op 22 juli 2024 20:23]

[Olaf van der Spek]

C en C++ zijn nog steeds de beste taal voor veel systeemprogrammeren waar je handmatig met geheugen werkt

C++: OK
C: why?
De enige reden om C te gebruiken is IMO een grote bestaande code base of misschien het niet beschikbaar zijn van een C++ compiler.
Anders lijkt mij (een subset van) C++ altijd beter.

[EraYaN]

Nouja omdat C++ kan resulteren in zeer matige code zijn er nogal wat invloedrijke mensen die er een pest hekel aan hebben, waardoor er erg veel in C geschreven wordt. En je hebt ook echt niet overal objecten nodig.

[Olaf van der Spek]

Aan het aantal security issues in C code te zien kun je in C ook zeer matige code schrijven.

En je hebt ook echt niet overal objecten nodig.

Is dat zo?
Kernels zitten in ieder geval vol met objecten..

[EraYaN]

Toch zijn kernels bijna allemaal in C.

[gast128]

Kernels zitten in ieder geval vol met objecten..

Er is een klein semantisch verschil tussen 'object based' en 'object oriented'. Bij de start van de ontwikkeling van Windows NT rond 1990 was het gebruik van portable C al een hele stap komend van een assembly achtergrond. C++ stond nog in de kinderschoenen toen. Later zijn wel delen van Windows NT in C++ geschreven (e.g. grafisch gedeelte; wellicht mag je dat niet als kernel zien). Hoe de verhouding nu ligt met Windows 10 weet ik niet maar het lijkt erop dat Microsoft zelfs zijn CRT in C++ heeft herschreven.

Bron:

• Inside Windows NT
• Showstopper!

[Hans1990]

Wat Olaf op doelt, is dat in de bvb Linux kernel verschillende drivers worden ingekoppeld door middel van structs die function pointers bevatten. Deze structs bevatten bijvoorbeeld verwijzingen naar de individuele init/close, ioctl en read/write functies voor een chipset driver, character/block device, etc.

State van drivers worden dus ook in (wellicht andere) structs bijgehouden. Waarschijnlijk bedoel je daarmee dat 'object based' wordt geprogrammeerd. Immers, al zou je de state van een ethernet driver chipset in globals bijhouden, dan zou je maar 1 chip tegelijk kunnen draaien, of 1 file tegelijk openen.

Echter als je op het punt komt dat enkel bepaalde functies manipulaties doen op die structs, begeef je snel richting een object georienteerde taal. Je kan in de std C library ook wel zien dat veel functies die file manipulaties doen, met de letter f beginnen en als eerste argument de file pointer nodig hebben. Dus of je nou:

fread(myBuffer, sizeof(float), 1024, fp);

of

fp.read(sizeof(float), 1024, );

schrijft, maakt dat vrij weinig uit. Nouja.. behalve dan de consistentie:

int fgetpos ( FILE * stream, fpos_t * pos );
size_t fread ( void * ptr, size_t size, size_t count, FILE * stream );

Dus hoera voor diegene die de ptr en stream argumenten wel eens omdraait. Zonder -Wall geen warning in GCC. En zelfs met -Wall "slechts" een warning. In G++ is het een keiharde error, zoals het hoort te zijn.

En zo kan je nog wel even doorgaan waarom function pointers en het "emuleren" van een C++ programmeeromgeving met function ptrs IMO meer ellende oproept dan problemen oplost. Ja als je zeer desparate en principeel aan C vast houdt kan het. Maar het is zeer foutgevoelig, de compilers zonder -Wall -Werror draaien is cowboy land, en je kan al die moeite besparen door 'gewoon' in C++ aan de slag te gaan.

Tuurlijk is het verleidelijk om een moderne C++ compiler bvb virtual methods te gaan gebruiken. Daardoor kan je (in sommige gevallen) vtables + run-time polymorphisme te introduceren. Echter, feitelijk is dat wat je in C met de hand aan het implementeren bent, dus zo'n groot verlies is het ook weer niet. De gevallen waarin C++ het zonder doet is pure winst.

C is m.i. nog toepasselijk als je portability of legacy code/omgevingen wilt gebruiken. Zelfs de haast script-taal like benadering van pointers en type casting in C (in vergelijking met C++) zijn mij de verloren debug tijd niet waard.

[Reactie gewijzigd door Hans1990 op 22 juli 2024 20:23]

[Immutable]

Objecten met Classes fuseer je trouwens logica met state. En kun je minder goed componeren. In Rust heb je state en logica gescheiden. Heel veel C programmeurs hebben inderdaad haat aan C++ en Classes.
Terwijl heel veel C en C++ programmeurs zich beiden kunnen vinden in het Object systeem van Rust. Gek he ?

[Verwijderd]

C is ideaal wanneer je een library wil bouwen waar het nadien eenvoudig voor is om er een language binding voor te maken. En C is ook de taal die oa. de Linux kernel gebruikt (maar ook tal van andere belangrijke kernels worden in C ontwikkeld). Dat wil zeggen dat de meeste kernel ontwikkelingen in C gebeuren.

Doe je aan embedded dat wat dichter bij de hardware staat, dan zal de fabrikant normaal gesproken altijd een C compiler klaar hebben staan. C++ soms. Niet noodzakelijk altijd.

[MSalters]

De typische embedded omgeving heeft een oude GCC versie als compiler, omdat een eigen compiler te duur is, en GCC up-to-date houden ook geld kost. Embedded is vaak armoe troef. Maar zelfs met een oude GCC heb je de front-end/back-end split, en krijg je dus G++ kado. ARM/Linux is de uitzondering, daar heb je embedded gewoon alles. Niet alleen C++, maar ook Rust en perl.

[Immutable]

Gelukkig gaat zowat de hele embedded wereld richting Cortex M cores. En de opensource Risc-V(in de nabije toekomst), welke uistekende ondersteuning heeft in nieuwe GCC versies en Rust.
Ja de zelfgebakken cores van bepaalde processor leveranciers moeten het inderdaad doen met GCC met hun eigen C achtige versie(die achterloopt...). Veel bedrijven willen dit gewoon niet meer, en willen gewoon kunnen werken met de nieuwste GCC. En dan is de overstap naar Rust heel gemakkelijk. (Maar het hangt ook af van de volwassenheid van de HAL's)
In ieder geval, de embedded wereld is zeer te spreken over de weg naar Rust. Omdat die wereld ook veel gebruik maakt van Misra C en waarbij Rust (niet alles) maar veel wel afdekt in de compiler. Dit zorgt dus voor kortere doorloop tijd en hogere kwaliteit van het product.

[Reactie gewijzigd door Immutable op 22 juli 2024 20:23]

[GertMenkel]

C wordt gebruikt door de kernel van ieder populair besturingssysteem. Op Windows kun je volgens mij nog C++ gebruiken, maar zelfs dan moet je nog bepaalde C API functies gebruiken voor dingen als strings en geheugenallocatie.

Qua pointers etc. is moderne C++ beter, daar kun je lastig omheen, maar daar kun je simpelweg gewoon niet altijd gebruik van maken. Zolang dat zo is, zal C actief gebruikt blijven worden.

[Kewne]

Het subset van C++ waar ze in systems programming vaak op uitkomen is geen gebruik van de STL/std namespace, geen templates en geen exceptions. Alles om de code size klein te houden en geen gebruik te hoeven maken van libstdc++. Dan blijft er echt heel weinig over behalve het keywordje "class" wat dingen niet noodzakelijk beter maakt, en dan is de keuze voor C99/C11 makkelijk gemaakt.

[Immutable]

Maar Rust met [no_std] tag, dus zonder std lib, kan veel meer als C. Daarnaast heb je nog steeds het geheugen model van Rust! Ik zie dat er grote interesse is in de C wereld naar Rust. Ook zonder std lib.
Je kunt eventueel bij bepaalde Processors zoals Cortex-M bijvoorbeeld nog wel een library toevoegen voor dynamisch geheugen. En dan kun je bijvoorbeeld wel gebruik maken van de std collecties. Iets wat je met C normaal gesproken niet hebt.

[MSalters]

Alsof dat uitmaakt, templates. std::array<int,5> versus int[5] is vooral een compile-time verschil.

[Ablaze]

C wordt regelmatig geprefereerd in de embedded wereld.
Sommige simpele C++ features worden wel gebruikt, zoals lijncommentaar en dergelijke.
Microcontrollers hebben vaak geheugen in de kilobytes, dus de std library wordt sowieso niet gebruikt. En dynamisch geheugen alloceren en instanties aanmaken ook niet. De code is vaak het kleinst en snelst als er functioneel wordt geprogrammeerd, sommige gedeelten in assembler.

[Hans1990]

Ik val ook persoonlijk erg over de quote dat C++ niet snel is. Letterlijk het eerst wat geciteerd wordt uitgedrukt. Waarom dan? Ligt dat aan de taal, de stijl van programmeren die je er op na houdt, of zo? Erg wazig.

Ik zou dan het liefst een example willen zien waarin een implementatie of abstractie in Rust t.o.v. C++ een negative cost heeft. Voor C++ vs C zijn die talloos te vinden, deels omdat C maar zeer beperkt is in compile-time computations/optimalisaties (constexpr, templates ) die gedaan kunnen worden.

Hetzelfde algoritme in C++ en Rust programmeren, compileren en dan zien welke sneller is geen benchmark van de taal. Dat is een benchmark van de gebruikte compiler IMO.

Dat Rust veiliger is dan C++ kan ik ergens wel inkomen. Er zitten hulpmiddelen in die kunnen helpen, die je in C++ kan negeren. Echter is dat zo een onvolledig verhaal als bvb te zeggen dat een auto met ESP veilig is. Sure, in sommige gevallen zal ESP de dag redden, maar auto's crashen nog steeds met ESP. En dat wil dus helemaal niet zeggen dat we meteen alle auto's zonder ESP maar moeten schrappen.

[Reactie gewijzigd door Hans1990 op 22 juli 2024 20:23]

[Zoijar]

He-le-maal mee eens. Iedereen die met Rust aan komt zetten heeft een hoog fanboy gehalte. Het erge eraan vind ik nog wel dat men denkt niet meer na te hoeven denken "want rust is veilig"; dat zijn dezelfde mensen die geheugen-slurpende applicaties bouwen in Java omdat je daar niet aan memory management hoeft te doen.

"C++ crasht vaak, is niet snel en is niet veilig." what a load of bs Dan moeten ze leren programmeren haha. Sowieso dat je je hele project baseert op welke taal het in geschreven wordt is al een enorme red flag; alsof dat goed design gaat geven, snelheid in GPU graphics, bruikbare en simpele APIs en structuur. Ik zou nooit iemand aannemen die zulke criteria gebruikt.

[yade]

Het is makkelijker om in C++ grove fouten te maken als iemand niet goed op de hoogte is van modern C++. Alle manieren om dingen fout te doen blijven bestaan in C++, maar nieuwe code kan stukken veiliger en stabieler geschreven worden mits je de best practices gebruikt, goed begrijpt wat ownership inhoudt en dat weet te communiceren.

Rust daarentegen is een goed alternatief, en ook een mooi ontworpen en out of the box veiligere taal.

Go vind ik overigens ook een mooie taal als leuke middenweg tussen C++ en Java/C#.NET. Go is tevens snel om in te ontwikkelen. Dat is iets waar Rust, en vooral C++ minder sterk in zijn.

Maar het statement: "Rust is sneller dan C++", vind ik gek en betekent niks.

• Er is in Rust sneller te programmeren dan in C++. Dat zou wel eens waar kunnen zijn.
• Rust compiled sneller dan C++. Dat weet ik niet. Ik denk het niet, maar dat zal van mate van TMP afhangen, alswel de structuur van een applicatie in C++.
• De code die uit Rust komt is sneller dan die van C++. Dat denk ik ook niet, als je ervan uitgaat dat de ontwikkelaar dezelfde code schrijft op de meest nominale manier in beide talen. Sterker nog, C++ heeft undefined behavior op plekken waar Rust 'veilige' probeert te zijn. De keerzijde zijn optimalisatie mogelijkheden die wegvallen in Rust.

Desalniettemin hoop ik dat Rust wat meer gemeengoed gaat worden, want ik krab toch regelmatig mijn ogen uit als ik naar C++ code zit te kijken.

Package management is ook in C++ een solved problem. Er zijn alleen veel oplossingen beschikbaar.

Zolang de packages uit source code bestaan is het prima te doen.

[Reactie gewijzigd door yade op 22 juli 2024 20:23]

[Wulfklaue]

Rust compiled sneller dan C++.

Totaal valse. Het probleem is dat veel mensen simpele code vergelijken met C++. Zolang je niets importeert en de boel klein houd ( aka benchmark code of zo van die dingen ), dan is Rust idd "sneller".

Het probleem zit hem zodra je meer code schrijft en een actueel programma maakt dat niet bestaat uit 100 lijn code en geen crates, dat je ineens de nieuwe wereld van LLVM binnenkomt. En dan valt die compile snelheid snel in elkaar en zie je bedrijven de oude "builds" richting uitgaan.

Ik ben de link vergeten maar er was een project dat vergeleek hoe snel de compiler waren zodra je lijn counts omhoog gingen. Rust en C++ waren gewoon elkaars broertjes dan begon de curve uiteen te gaan, waarbij Rust begon zelf trager te worden wegens de meer uitgebreide compile checker.

Er is in Rust sneller te programmeren dan in C++

Dit hangt enorm af van wie de code schrijft nietwaar. Ik kan je verzekeren dat ik in C++ sneller zat te programmeren, dan in Rust dat constant mijn handje probeerde vast te houden.

Rust is best een trage taal om aan te leren. Kan je sneller schrijven, ja ... met een grote MAAR erachter. Zo lang je idiomatic Rust schrijft maar zodra je buiten de lijntjes moet kleuren ( voor performance redenen ), is Rust net zo een clusterbol als C++ er iets misloop.

Rust is gewoon een opgekuiste C++, waarbij men een betere compile checker heeft en een meer beperkte pad van wat is toegelaten. Programmeer je moderne C++, en blijf in in datzelfde pad, dan valt die "sneller" ook weg.

De code die uit Rust komt is sneller dan die van C++.

De code dat de C++ gebaseerde LLVM compiler produceert ... gniffel...

Voor de meeste zaken is gewoon een zaak van waar de compiler beter geoptimaliseerd is. Daarom kan je verschillende C++ compilers nemen van verschillende bedrijven en verschillende snelheden bekomen voor de exact dezelfde C++ code.

Is C++ daarom sneller dan C++?

Rust word gewoon overhyped en dat loopt soms (vaak) de spuigaten uit. Je ziet dat ook terug in de Stack Overflow Developer Survey iedere keer. Zodat men deze doet, zie je overal de hype om iedereen te pushen in de community om hun voorkeuren uit te spreken. Het gevolg is dat je een vertekend beeld krijgt. Of bij andere taal topics, dat er altijd van die fanboys langskomen en roepen hoe "het beter in rust geschreven is". Een bijna Cult mentaliteit...

Rust community doet me echt denken aan de Ruby On Rails fanboys van jaren geleden, dat PHP gingen vervangen en waar is Ruby On Rails deze dagen op het web? Ik wacht nog altijd op die revolutie.

Dit artikel is gewoon de zoveelste??? Waar men gewoon de bindings herschreven heeft van C++ naar Rust en doet alsof het een speciaal ding is. Diezelfde bindings dat ook herschreven worden in D of Go of andere talen.

Tussen haakjes: Waar zijn de Rust jobs? Vergelijk dit eventjes met de Go jobs... De taal waar men minder zit te hypen omdat het zo een "saaie" taal is.

Vreemd genoeg ( niet ) zie je dat de adoption rate in bedrijven veel hogere zit bij Go dan bij Rust. Makkelijker aan te leren, dezelfde voordelen van een goede checker, GC is goed genoeg voor de meeste projectem, package manager, VEEL meer packages, enorm stabiele taal dat geen nieuw features iedere 6 weken krijgt. Rara waarom Go meer gebruikt word deze dagen in bedrijven.

Rust is gewoon de punker om de hoek dat volop zit te roepen voor aandacht maar dat weinig bedrijven volop willen naar committent omdat het meer risico's omvat.

[Reactie gewijzigd door Wulfklaue op 22 juli 2024 20:23]

[Immutable]

Maar Rust is denk ik wel een zeer breed inzetbare taal. Ik denk wel 1 van de breedste. Jij zegt bijvoorbeeld GC is goed genoeg voor de meeste projecten. Klopt, maar dat maak het wel beperkt waarbij Rust heel breed inzetbaar is.
- Low end microcontrollers (Cortex M, Risc-V), tot aan het schrijven van een complete webapplicatie zonder enige vorm van Javascript aan te raken via webassembly. Tot aan het draaien op computers met heel veel cores, waarbij Rust een stuk minder hoofdpijn bezorgd met multi-cores dan andere systeemtalen.

Rust is zowel verticaal als horizontaal heel breed inzetbaar. Breder als C zelfs. Al heeft C nog wel het voordeel van bepaalde niche platformen, waar Rust niet op draait.

Ja Rust is een taal dat eigenlijk allemaal wijze lessen uit C++ heeft geleerd, welke in C++ nooit geïmplementeerd kunnen worden omdat je zit met back compatibiliteit. Veel "default" dingen in C++ zijn niet de weg die je eigenlijk wil bewandelen. En de goede wegen zijn vaak verborgen of moet je net even weten. Dit is echt veel beter geworden en C++20 is echt super.

Ik denk dat jij denkt dat veel Rust programmeurs C++ haten o.i.d. het is geen wedstrijd! Uiteindelijk is Rust gewoon een evolutie van C++ met lessen uit andere talen.

Rust en ruby on rails? Niet echt... Rust is juist bij de ultraconservatieven welke echt veilige code willen bouwen juist erg interessant. Denk aan systemen welke zich moeten houden aan Misra C. Het is niet echt een hype. Juist omdat niet performance op 1 staat, maar juist de correctheid van de code. Want je moet toch echt soms uit de veilig bubbel stappen met unsafe om bepaalde optimalisaties te doen.

[Killemov]

Mooi verhaal. Als Rust DE programmeertaal is voor iedereen en voor elk doeleinde, dan zou het een fantastische proof-of-concept zijn als Firefox en Thunderbird in deze taal wordt herschreven.

[diondokter]

Ehhh: https://github.com/servo/servo

(Servo is de engine die (een deel van) firefox aanstuurt en is volledig in Rust)

[Killemov]

Ehhh: https://github.com/servo/servo
(Servo is de engine die (een deel van) firefox aanstuurt en is volledig in Rust)

Zucht, ernstig gevalletje van klok en klepel. Servo is EEN browser-engine, wel volledig geschreven Rust, wel gesponsord door Mozilla maar heeft op dit moment niets met Firefox en Thunderbird te maken.

[diondokter]

Laatste kopje: https://research.mozilla.org/servo-engines/ (vandaar de 'een deel van')

[Crotchy]

C++ is niet snel?

Kom op zeg... Rust is trager dan C++ (en dan bedoel ik niet alleen compilen wat tergend traag is) tenzij je unsafe Rust schrijft, maar dan ben je direct de voordelen m.b.t. veiligheid kwijt.
Dit artikel leest als een advertentie, waarom niet ook de andere kant belichten?

[PrisonerOfPain]

Hoewel Rust inderaad problemen heeft met compile tijden, is het op de CPU over het algemeen wel gewoon sneller can C++; zie bijvoorbeeld de Debian Language Shootout https://benchmarksgame-te...rksgame/fastest/rust.html

[demonite]

Leuke link, maar heb je 'm wel goed bekeken? Met name het "vs C++" gedeelte (want het begint met vs C, zonder de ++)
Rust Vs C++ (enkel kijkend naar het aantal seconde):
- Rust 3 vd 10x het snelste.
- C++ 7 vd 10x het snelste.

[dec0de]

Ik ben wel benieuwd welke C flags ze gebruiken. Want dat C++ sneller is dan C is natuurlijk complete lulkoek. (Als C minder wint van rust dan C++ zou C++ sneller moeten zijn)

Wellicht -Os ipv -O2 of -O3 gebruikt (of als je écht snelle programmas wilt hebben: -Ofast, dan is C echt bloed snel)

overigens zijn zowel rust, C en C++ erg snelle talen en zal het grootste verschil zitten in de programmeur

[Reactie gewijzigd door dec0de op 22 juli 2024 20:23]

[tmnvanderberg]

"Want dat C++ sneller is dan C is natuurlijk complete lulkoek."
Dit is een oud en hardnekkig broodje aap Bijvoorbeeld: numerieke bibliotheken maken veel gebruik van templates om te optimaliseren. Als een stuk "handgemaakte" C code optimaal snel is kun je altijd een equivalente (of zelfs gelijke) implementatie in C++ schrijven. C++ >= C.

[dec0de]

C++ < C, C++ = C, C++ >= C, C++ > C

alle 4 de statements kloppen. C++ is redelijk vaak inferieur aan C. toch is het ook vaak superieur aan C. het klopt dat als je extern C gebruikt dat er geen verschil zit tussen C en C++. maar dan kun je beter geen C++ gebruiken, maar gewoon direct C.

anyway: C++ is niet sneller dan C. ja, als je C code schrijft in C++ is er geen verschil, maar dat is niet eerlijk. we hebben het over C++ code (waar je de voordelen van C++ gebruikt) vs C (waar je de voordelen van C gebruikt). en dan is C bijna altijd sneller.

voor wat ik doe is het toch echt C > C++; voor veel mensen zal het anders om zijn, en dat is ook prima, daarom bestaan ze ook allebij

[demonite]

Bij deze benchmarks is te zien dat C++ > Rust > C

En dat is eerlijk gezegd ook wat ik zou verwachten. De taal zelf is natuurlijk het probleem niet, eerder dat er in vergelijking met andere talen nauwelijks nog in geïnvesteerd wordt.

[MeMoRy]

O3 is niet zoveel sneller dan O2. Sommige algos worden er zelfs trager door. En Ofast gebruikt niet-standaard optimalisaties, wat risico's met zich meebrengt.
Altijd eerst benchen voordat je conclusies trekt.

[dec0de]

-O3 is maakt bij gcc niks uit, bij clang soms wel (qua snelheid)

[Crotchy]

https://benchmarksgame-te...ame/fastest/rust-gpp.html
Zie toch echt dat C++ in de meeste gevallen een stuk sneller is, en dat is met GCC.
Ik verwacht dat als je clang/llvm met O2/O3 er tegenaan gooit dat het overal sneller is.

[MSalters]

clang/llvm is een serieuze concurrent voor GCC, maar vergeet ook vooral Intel niet. Mits je intel hardware target is dat vaak de snelste compiler, zeker in combinatie met Intel's eigen libraries.

Je ziet daar dus een belangrij k voordeel van C++: er zijn meerdere serieuze concurrenten die elkaar scherp houden. Ook Microsoft heeft een serieuze compiler; ik moet nog maar afwachten of Intel en Microsoft een Rust compiler gaan bouwen.

[PrisonerOfPain]

Ik hoop (en verwacht) dat als Microsoft gaat contributen aan Rust (ze hebben al een aantal kleinere contributies gedaan in de vorm van winrt en com support) dat ze dat gewoon aan de defacto rust compiler doen. Microsoft is overigens al een van de belangrijkste sponsoren van het project.

[youridv1]

Tenzij je natuurlijk even doorscrollt en ook de disclaimer leest "look at the source code" Rust is niet altijd sneller.

De benchmarks die je toont tonen zowel rust als c++ aan de winnende hand afhankelijk van de test. Ik zie namelijk ook tests waar c++ 30+% sneller is

[Reactie gewijzigd door youridv1 op 22 juli 2024 20:23]

[BonzO]

Je moet wel de tests zelf aanklikken, dan zie je een heel ander beeld. Dit is het vergelijken van de eerst ingezonden tests. Er zijn maar 2 tests sneller in Rust, n-body & fannkuch-redux.

[NC83]

Daar waar het sneller is wil het nog wel eens behoorlijk meer geheugen gebruiken, dat is niet in alle situaties een win. Vooral voor games is dat geen win. Blijkbaar was ik naar de C sectie aan het kijken

[Reactie gewijzigd door NC83 op 22 juli 2024 20:23]

[diondokter]

C++ is natuurlijk ook snel en het is onzin om anders te zeggen.
Zo is het ook onzin om te zeggen dat Rust langzamer is dan C++.

In de debug builds zitten allerlei checks op array accesses en integer operations (om overflow te checken) en dit is natuurlijk langzaam. Maar dit is alleen het geval wanneer de compiler niet vooraf weet of overflow of out of bounds access niet kan gebeuren. Als je slices gebruikt samen met iterators, dan worden die checks al niet gedaan.

Daarbij heeft het wel of niet zijn van unsafe van een stuk code ook totaal geen effect op performance.

Als je een leuk stuk wil lezen: http://dtrace.org/blogs/b...erformance-of-c-and-rust/
Het is geschreven door Bryan Cantrill. Hij was de CTO van Joyent (bekend van Node.js) en heeft nu een nieuw bedrijf op gericht.

[misterTweakers]

Mij lijkt dat deze persoon dit ook wel weet, maar dat hij eerder iets in de richting bedoelt van dat het over het algemeen sneller is om Rust code te schrijven vergeleken met C++ code, omdat het makkelijker is. Als het op deze manier bedoeld werd staat het er wat ongelukkig.

[Menesis]

"In het ideale geval ontstaat er een community die eigen packages maakt en waarbij iemand zegt ‘ik heb deze vette shader gebouwd’, die anderen dan weer kunnen gebruiken."

Naja, dat kan gelukkig al makkelijk met zowel Unity en Unreal..
Hier zijn bijv 1371 packages met shaders voor Unity.

[Reactie gewijzigd door Menesis op 22 juli 2024 20:23]

[SG]

Je quote iets dat gaat over de acceptatie en migratie naar nieuwe taal. De contex is meer wat voor gedrocht C++ geworden is. De basis wat beginner doet met C++ verschild niet veel met ander talen. Totdat je memory moet managen en bewust moet zijn van lifetime van variabelen en objecten. En pointer en references en welke object welke ander bezit shared pointer gedoe Etc. Kijk je naar STD libary code dan met de vele && er doorheen de templated manie en dan zijn heel veel andere talen stuk cleaner. In veel cleanere taal met beperkte legacy balast kan met intensiever programmeren in 5 jaar op hoog niveau komen. C++ loop je mogelijk voor 10 jaar tegen je limieten en kun dan nog niveau hoger. Er zijn paar honderd guru’s die high performance en zeer geavanceerde C++ schrijven en paar miljoen gebruikers in de trenches van beginner tot intermediate.
Ik programmeer te weinig om flink te groeien in welke taal dan ook dus blijf haken op beginners niveau. Rust is mij onbekend maar C++ vervanger zonder nukken en legacy van C++ zoals D en Swift en dus ook Rust lijkt mij erg interessant.

[peke]

Ik werk zelf al 10 jaar als C++ developer. Buffer overflows zijn eenvoudig detecteerbaar tijdens de runtime als men linkt met libAsan. In het ideale geval heb je 100% code coverage met je unit tests en dan haal je quasi alles er zo uit.
Ik heb het persoonlijk ook wel een beetje gehad met de wildgroei aan talen. Waarom? Een nieuwe taal is op zich geen probleem maar alle api's en frameworks die erbij horen leren kennen is imho echt zonde van de tijd als je al zeer vertrouwd bent met je huidige platform. Ik gebruik vaak Qt en std. Ik snap ook wel dat je snel met Python enzo veel kan doen maar ik kan dit niet, ik ken al de bijhorende frameworks niet en ik ga echt geen maanden investeren om het te leren kennen om dan na X jaar te horen dat nu Rust de nieuwe trend is dus die moet je dan hebben. Je kan op die manier ook nooit expert worden in iets als je al je aandacht moet spreiden over al die technologiën ... die in feite tot hetzelfde resultaat leiden.

[Immutable]

Maar is dat ook dan niet een beetje egoïstisch? Zo lang je zelf jong bent, mag alles innoveren en kun je lekker meekomen, en is dat heel leuk. Maar als je wat ouder aan het worden bent, moet alles ineens stilstaan. Ik zie dat echt bij heel veel mensen die ouder aan het worden zijn. En ik snap dat ook wel omdat dat gewoon ermee te maken heeft dat de neuroplasticiteit van je hersens steeds minder wordt naarmate je leeftijd toeneemt.

Gelukkig werk je met C++, dat is een taal die zeker nog wel 20 jaar super relevant zal blijven.

Misschien moeten mensen wat meer bewust worden van het feit dat het vaak aan hunzelf ligt, dan aan de rest van de wereld. Alles vanuit je eigen perspectief kijken is een soort cognitieve bias.
Jij kunt bijvoorbeeld veel last hebben van "Confirmation Bias" waarbij je alleen dingen vertrouwd die je kent, en vanouds zijn. Ik kan bijvoorbeeld last hebben van de "pro innovation bias" waarbij ik dus te weinig details vergeleken heb tussen bijvoorbeeld C++ en Rust en de Pro's en Con's slecht heb afgewogen.

En in de systeemtalen wereld is er helemaal geen grote wildgroei aan talen. Dat is een foute aanname. Je moet wel talen categoriseren met elk hun eigen doelgroepen.
Python kun je absoluut niet vergelijken met Rust.

[Bartdo]

Ik zie dat veel mensen reageren op dit artikel zonder veel te weten over Rust. Hierbij links naar twee video's over Rust op YouTube.

Deze is van een medewerker van Microsoft die vertelt over het gebruik van Rust binnen hun organisatie. Hun keuze voor Rust is zeer rationeel; het gaat om het besparen van kosten:
https://www.youtube.com/watch?v=NQBVUjdkLAA

En deze van Bryan Cantrill:
https://www.youtube.com/watch?v=HgtRAbE1nBM

Deze mensen zijn niet de eerste de besten en ze zijn zeer positief over Rust als vervanger voor C en C++.

Zelf ben ik een tijdje geleden gebonnen met de tutorial op de Rust-site. Het lijkt me een mooie taal en herkende de invloed uit Haskell (wat ik ook een mooie taal vind). Voor het werk dat ik zelf doe is Python veel geschikter en ik ben dan ook helemaal geen expert op het gebied van low level talen.

[farlane]

Ik vind C++ geweldig om mee te werken, maar ik zie in Rust een goed kanshebber als vervanger (op de lage termijn) van C++.
Niet omdat het sneller zou zijn maar simpelweg omdat het moeilijker is om fouten te maken. Alleen al de tig manieren om in C++ in undefined behaviour land te komen (voorbeeld) zijn genoeg om gillend weg te rennen (als het niet zo uitdagend zou zijn om het te willen begrijpen )
Ik denk ook dat er maar weinig mensen zijn die alle finesses van de taal C++ begrijpen en kunnen overzien, myself included. Het feit dat er op SE ellenlange discussies zijn of iets wel of niet zou mogen/kunnen en welke combinatie van C++ standaard paragrafen dat uit volgt is een indicatie dat de complexiteit eigenlijk niet meer te bevatten is voor het gewone volk.

Verder is de formulering nogal clickbaiterig. Vraag me af of dat de letterlijke formulering was van @PrisonerOfPain ?

[Reactie gewijzigd door farlane op 22 juli 2024 20:23]

[PrisonerOfPain]

Normaalgesproken is mijn mening hierover inderdaad een héél stuk genuanceerder en had ik beter op die nuances in kunnen duiken in het interview. En ik had dan ook graag een andere titel gezien, maar ja. De snelheid van Rust is één van de dingen geweest waar we naar keken toen we de taal evalueerden en toen was de maatstaf vooral dat t niet trager moest zijn, maar veel belangrijkere dingen waren eigenlijk het ecosysteem mbt crates, de openheid van de community en de mate van professionaliteit waarmee dingen gedaan waren.

Ik hoopte vooral over te brengen dat we in Breda mee bouwen aan goede moderne compiler tech, graphics en games. Iets dat een vrij zeldzame combinatie is. Dit project lost een hoop problemen waar we in AAA gamedev land tegenaan gelopen zijn met de jaren.

[farlane]

Normaal gesproken is mijn mening hierover inderdaad een héél stuk genuanceerder [...]

Ik twijfelde er eigenlijk niet aan De formulering zorgt er voor dat de aandacht wordt afgeleid van waar het eigenlijk om gaat, zie beneden. Je weet ongetwijfeld ook hoe de C++ community de "Rust is God" beweging ervaart

Ik hoopte vooral over te brengen dat we in Breda mee bouwen aan goede moderne compiler tech, graphics en games. Iets dat een vrij zeldzame combinatie is.

Daar mogen jullie (en "wij") best trots op zijn

[Webgnome]

Ik heb zelf nooit een letter c++ geprogrammeerd maar er genoeg over gelezen, gekeken en geluisterd en sta een beetje te kijken van de claims die gemaakt worden dat het crashtastic is, onveilige code kan produceren etc etc. Dat is toch bij elke taal het geval? Als ik om maar iets te noemen een sql injectie niet goed genoeg afhandel wie is er dan onveilig? De taal of de persoon aan de knoppen.

Ben het verder wel eens met @johnbetonschaar. Dit artikel leest als een advertorial. Maak dat er dan ook van.

In zijn visie ontstaat er een modulair platform dat beter schaalt dan het werk aan die engines.

Heel nobel streven maar het grote gevaar van modulair en package managers is de dependencie hell die je daardoor gaat krijgen. Dat zie je bij alle platformen die ook maar iets met package managers doen. Dat kan op den duur hartstikke mis gaan.

[Lijmer]

Rust is zo opgebouwd dat alles wat zou kunnen leiden tot een crash, expliciet ingetypt moet worden. Elke case moet afgehandeld worden, of er moet een zogeheten `unwrap` op gedaan worden, waarbij panic wordt gecalled en het programma crasht. Een bijkomend voordeel is dat je bij een panic ook gelijk een duidelijke stack trace kan verkrijgen.

Daarnaast heb je ook geen last meer van pointers, omdat er gebruikt wordt gemaakt van een borrow en lifetime systeem. Hierbij is het wat meer werk om je code werkend te krijgen, maar het geeft wel de garantie dat als het compiled dat het correct is.

Nu is dit niet altijd gewenst, dus biedt Rust ook een unsafe keyword aan, waarbij je wel lekker met pointers aan de gang kan gaan voor meer geoptimaliseerde code, maar daarbij ook al die safety voordelen verliest.

Het grootste verschil dat ik zelf heb gemerkt is dat met C++ ik regelmatig met een debugger issues kon gaan doorzoeken omdat ergens iets out of bounds schreef, of een ding niet was gedeallocate, of een pointer die NULL was, en met Rust heb ik dat nu in een half jaar pas één keer hoeven doen in een kleine snippet unsafe code.

[Reactie gewijzigd door Lijmer op 22 juli 2024 20:23]

[diondokter]

Daarbij is het ook zo dat een stukje unsafe code niet gelijk je hele programma unsafe maakt. Natuurlijk kan daar een fout in zitten, maar het grote voordeel is dat je niet je hele programma door hoeft te zoeken zoals in C en C++. Een memory error zit zeker weten in unsafe code, dus je hoeft alleen die plekken te checken.

Hoeveel unsafe is nodig? In een gewone desktop applicatie eigenlijk niks. In de embedded bootloader die ik geschreven heb zitten maar 2 regels unsafe code. 1 om de stackpointer aan te passen en 2 om naar de applicatie code te springen.

[Lijmer]

Ja klopt, zolang je unsafe snippet vrij klein is, kun je alle mogelijke edge cases en errors vrij makkelijk afbakenen en het zo 'safe' maken. Ik was zelf ook aangenaam verrast hoe weinig unsafe code je nodig hebt. Ik heb het tot nu alleen echt nodig gehad voor FFI layers om met C en C++ code te kunnen werken in Rust (met name voor Vulkan).

[PrisonerOfPain]

Heel nobel streven maar het grote gevaar van modulair en package managers is de dependencie hell die je daardoor gaat krijgen. Dat zie je bij alle platformen die ook maar iets met package managers doen. Dat kan op den duur hartstikke mis gaan.

Ja klopt, dat is inderdaad een probleem en daar moet je gewoon tijdens je ontwikkel proces op letten. Embark heeft een tool gemaakt (cargo deny) die een deel van die problemen voor je op kan lossen. En hoort het prunen van dependencies gewoon bij software development, net als dat refactoren dat doet.

[Reactie gewijzigd door PrisonerOfPain op 22 juli 2024 20:23]

[RoestVrijStaal]

Vreemd, de .adv-prefix staat niet in de titel van het artikel. Het artikel leest als een advertorial.

Ik vind dat de Rust programmeertaal in dit artikel iets teveel gepresenteerd wordt als een "Silver bullet" dat alle problemen oplost. Rust heeft bijvoorbeeld geen garbage collection, dus net als bij C++ moet je als programmeur zelf de RAII conventie volgen.
Die RAII-postit op je scherm heb je bijvoorbeeld bij het andere C++-alternatief Go weer niet nodig, want die heeft weer wel garbage collection.

Waar de haat tegen C++ vooral zit, zijn juist de zaken die C++ van C "overgeërfd" heeft en natuurlijk ook in C++ kunt gebruiken, maar inmiddels zitten er in de STL veilige alternatieven voor.

En dat er op een "vragensite" als StackOverflow het meest besproken programmeertaal Rust is, baart mij juist zorgen over de kwaliteit van de documentatie over de taal en ecosysteem.

[Reactie gewijzigd door RoestVrijStaal op 22 juli 2024 20:23]

[diondokter]

De documentatie is juist geweldig!

Ten eerste heb je 'the book' wat een super introductie is voor de taal: https://doc.rust-lang.org/book/
Verder is ook de standard library goed gedocumenteerd: https://doc.rust-lang.org/std/index.html
Elke library die beschikbaar is in de package manager heeft de documentatie online: https://docs.rs/async-std/1.6.5/async_std/ (Hoe goed deze documentatie is, ligt natuurlijk aan de makers van de library. Maar omdat de tools gestandaardiseerd zijn en de documentatie altijd online komt, zorgen de meeste mensen wel dat dit goed voor elkaar is)

[Immutable]

Het geheugen management probleem is een probleem wat niet opgelost is met 1 ultieme oplossing die beter is als alle andere oplossingen.

Je hebt dus eigenlijk alleen maar oplossingen die beide Pro's en Con's hebben. Een GC is tevens geen "silver bullet" om in jou termen te blijven. GC heeft juist netto on de streep meer problemen dan bijvoorbeeld RAII, echter is het voor de meeste problemen in ontwikkelland een prima oplossing en kostenbesparend in het ontwikkelproces.
Zoals C++ het doet op de handmatige manier heeft weer voordelen tegenover een GC, maar ook weer nadelen.

Rust heeft dus een andere oplossing voor dit probleem aangehouden, welke onder de streep zowel productiever is.(Dus meer richting de oplossing van een GC) Als meer performance en deterministisch is. (Dus meer richting de oplossing van Manueel geheugen management)
Het idee is om juist netto onder de streep dichterbij een bete oplossing te komen die beide Pro's van de GC en C++ manueel geheugen management samen probeert te brengen. Maar, ook hier zit een nadeel aan... lange compileer tijden bijvoorbeeld.

Alles in deze wereld bestaat uit trade-offs, maar hier en daar kunnen we de trade-off's zo buigen dat we onder de streep meer resultaat hebben.