Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door Tweakers Events

Martin Carton (Prodrive Technologies) over Rust: “Vaak beter dan C++”

21-01-2020 • 13:45

63 Linkedin

Voor elke developer is het een belangrijke vraag: wat is de volgende programmeertaal waarin ik me zou moeten verdiepen? Volgens Martin Carton, software engineer bij Prodrive Technologies, verdient Rust een kans. Sinds 2015 is hij betrokken bij het project en de community erachter. Tijdens de Developers Summit 2020 geeft hij een masterclass waarin hij Rust vergelijkt met andere opties, met name C++.

De programmeertaal Rust is ontstaan vanuit het idee om betrouwbare en efficiënte software te bouwen. Deels geïnspireerd op C en C++, maar met de nodige verschillen, is het vooral een functionele programmeertaal die focust op veiligheid. De Franse software engineer Martin Carton maakt deel uit van de Rust-community en is een van de voornaamste ontwikkelaars van een veelgebruikte tool voor Rust: Clippy. De naam is natuurlijk een grap en een verwijzing naar de controversiële Microsoft Word-assistent Clippy de Paperclip. Clippy voor Rust valt de gebruiker niet lastig met ongevraagde adviezen, maar helpt developers hun code te verbeteren met een set handige utilities.

Project zit in de lift

Carton woont sinds enkele jaren in Nederland, in de buurt van Eindhoven waar hij werkt voor Prodrive Technologies. Daarvoor studeerde hij Informatica en Toegepaste Wiskunde aan een universiteit in Toulouse, waar hij in 2015 afstudeerde. Als student maakte hij kennis met C++ en Rust, waarvan in 2015 de eerste stabiele 1.0-versie verscheen. “Toen ik ermee begon was het nog een kleine community, maar die is sindsdien flink gegroeid. Ik heb een aantal pull-requests gedaan voor de compiler. Maar heb me vooral gericht op Clippy, wat aanvankelijk een kleinschalig sideproject was, maar inmiddels een belangrijke tool voor Rust. Ik hoop dat ik heb kunnen bijdragen aan dit succes. Op dit moment zijn het vooral anderen die aan Clippy werken, zelf kom ik er niet meer zoveel aan toe als ik eigenlijk zou willen.”
Met Rust, in 2010 begonnen door Mozilla als open source-project, was het eigenlijk liefde op het eerste gezicht. “Ik ben altijd wel geïnteresseerd in het leren van nieuwe talen. Ik merkte al snel dat het een mooi alternatief voor C++ was; in essentie dezelfde doelgroep, maar met moderne features en tooling. En anders dan C++, dat eigenlijk een voortzetting is van C, is men bij Rust vanaf nul weer begonnen met een andere basis. Daarbij is echt afgevraagd: wat willen we met deze taal? En dat merk je.” Rust voelt modern aan, vanwege tooling voor documentatie en een officiële package manager. “Wanneer je wil beginnen met Rust maakt de package manager het je gemakkelijk. Dat is een verschil met C++, waarbij het aanvankelijk lastig is om alle tools te vinden. Alles is beter met elkaar geïntegreerd en hoewel er nog altijd een behoorlijke leercurve is met Rust, maak je hierdoor een snelle start.” Carton verwijst ook naar de behulpzame community, onder meer op Stack Overflow waar Rust al vier jaar op rij de populairste taal is.

Rust roest niet

Inmiddels werken vanuit de community honderden developers aan Rust, vaak in hun vrije tijd, al zijn er ook bedrijven die bijdragen. Onder meer Microsoft en Amazon hebben interesse getoond in Rust en Carton hoopt dat ontwikkelingen als deze bijdragen aan een verdere groei. “C++ blijft een belangrijke programmeertaal en veel grote projecten maken er gebruik van. Het kost veel tijd om Rust daarmee te integreren en dat zal ook niet overal gebeuren. Programmeurs met kennis van C++ zijn er volop, Rust-developers zijn wat lastiger te vinden. Bij nieuwe initiatieven ligt dat anders. Bij Prodrive Technologies bijvoorbeeld zijn de twee meest gebruikte talen C++ en C#, maar daarnaast gebruiken we sinds ongeveer twee jaar Rust. Dat gebeurt vooral in kleinere projecten waar wij normaal gesproken C++ zouden gebruiken, maar waar de betere integratie, de libraries en tooling van Rust voordelen bieden."

Prodrive Technologies is een grote internationale speler op het gebied van elektronische apparatuur, met vestigingen in Europa, Noord-Amerika en Azië. Klanten komen uit uiteenlopende markten, waaronder de automotive en (maak)industrie, de medische wereld, energie en infrastructuur. Een moderne low-level programmeertaal als Rust biedt voordelen in onder meer robotics-projecten. "Een taal zoals Rust helpt bij het voorkomen van veelvoorkomende bugs in C++. Daarbij maken de moderne features en tooling het gemakkelijker om programma’s met Rust te ontwikkelen."

Tegelijkertijd ziet Carton vanuit de hoek van webdevelopment de aandacht voor Rust toenemen. “Ook op websites kom je veel low-level tech tegen, bijvoorbeeld complexe algoritmen of games. Nu wordt er vaak gebruik gemaakt van technologie die daar eigenlijk niet voor geschikt is en daardoor te veel resources gebruikt. Rust is ook hiervoor gemaakt.”

De community staat klaar om te helpen

Met zijn masterclass in Utrecht hoopt Carton meer developers enthousiast te maken voor Rust. “Ik zal het op verschillende punten vergelijken met alternatieven, vooral C++, en uitleggen waarom het zo’n goede keuze is. Tegelijkertijd wil ik ook eerlijk zijn over de nadelen, zoals een wat steilere leercurve dan sommige andere talen. Ik hoop dat ik anderen kan overtuigen dat de voordelen de nadelen waard zijn en dat zij zouden moeten overwegen om Rust te leren. En mocht je de stap maken, dan zijn er online meer dan genoeg resources te vinden om te beginnen. De community staat klaar om je te helpen. Er zijn veel tutorials te vinden en er is zelfs een boek geschreven om nieuwkomers wegwijs te maken in Rust.”

Meer weten over Rust? Kom ook naar de Developers Summit 2020 op 13 februari in DeFabrique in Utrecht!

Koop je ticket

meer-informatie-transparant

Reacties (63)

Wijzig sortering
Prima verhaal, en best wel gebruikelijke argumenten.
Maar dit soort discussies zijn heel vaak een subjectieve zaak. En als ik dan zie wie deze meneer Carton vertegenwoordigd, lijkt dit meer op een veredeld marketing praatje.
Er wordt vergeleken met c++, vanwege dezelfde doelgroep, maar waarom zijn die hetzelfde? In mijn beleving is c++ niet een functionele taal maar eerder een OO taal?
Rust zal best prima zijn, maar ik krijg nu voornamelijk een gekleurd beeld voorgeschoteld.
Rust is toch gewoon ook OO? En het heeft ongeveer dezelfde doelgroep, high performance, vrij low level, maar dan moderner en vooral veiliger.
Neen, Rust is geen OO-taal. Maakt natuurlijk niet uit, op zeer specifieke "simulatie"-situaties na is OO niet inherent beter om je applicatiedomein in uit te drukken dan andere paradigma's. Voor veel developers is het echter zo dat de talen die ze kennen in twee categorieën vallen: ofwel OO en nieuw'ig (Java/C#/Kotlin/Python/recente PHP/etc.), ofwel niet-OO en oud (C/Cobol/de oude manier van JS schrijven hoewel JS altijd al prototype-gebaseerde OO had/etc.). Daardoor denken ze verkeerdelijk dat vanzelfsprekende abstractiemechanismen zoals "data hiding", of zelfs zaken als polymorfisme, enkel voorkomen bij OO-talen. Dat gezegd zijnde is Rust ook niet strict genomen een (puur) "functionele taal".

Rust is zeker een goede kandidaat voor de grote meerderheid van nieuwe projecten die anders in C, C++, en zelfs Java, Scala, Kotlin, C# of F# geschreven zouden worden. En ook bij het opsplitsen van bestaande monolithische codebases in een microservices-architectuur kiezen ze er bij ons soms voor om één of meer van de services op termijn in Rust te herschrijven. In-gelinkte libraries herschrijven doen we zelf (nog) niet, maar we hebben eigenlijk wel al wat dependencies vervangen door Rust-gebaseerde alternatieven...
Rust is zelfs niet bij benadering een functionele taal. Functionele talen zijn F#, Scala, Haskell, Lisp en dergelijke. Rust is een procedurele taal.

Polymorfisme is een eigenschap van objecten in een type-systeem met overerving, namelijk dat objecten van een afgeleide klasse gebruikt kunnen worden in de plaats van objecten van de basis-klasse. Daarvoor zijn objecten dus vereist, hetzij in een OO-taal, hetzij in een OO library.
Rust gebruikt geen overerving om polymorphisme te bereiken. Traits lijken op interfaces, maar niet op (abstracte) classes, onder meer omdat ze door bestaande structs (uit een andere module) geïmplementeerd kunnen worden. Een bestaande class van een nieuwe class laten overerven is volgens mij niet mogelijk (misschien met reflectie).

Verder is elke classificatie in procedureel, object georiënteerd, functioneel etc. academisch. Weinig talen zijn puur genoeg. De meeste object georiënteerd talen zijn een (al dan niet) strict superset van een procedurele taal, hebben functionele mogelijkheden etc.

[Reactie gewijzigd door 84hannes op 21 januari 2020 18:57]

Ik kan wel meer applicaties bedenken dan simulations die buitenproportioneel veel baat hebben bij OO.

Maar hoe meer ik erover nadenk, hoe groter de umbrella term "simulation" software kan zijn.

Op zich kunnen we air/ship traffic control, baggage/stock inventory, videogames, en dingen zoals crowd monitoring/tracking ook allemaal als "simulations" beschouwen.

Misschien heb je het toch goed verwoord.
Voor veel developers is het echter zo dat de talen die ze kennen in twee categorieën..
Wat dan gelijk bewijst dat ze de talen niet echt kennen.
Het is OO zonder overerving.
Dat dacht ik ook, totdat ik me in widgets/GUIs (met name Druid) ging verdiepen. Het veelgebruikte OO-concept waarbij iedere widget een parent heeft en parents en children links naar elkaar hebben werkt heel slecht met rusts exclusive mutability concept, daar wordt een OO-werkwijze projecteren op Rust opeens heel lastig.
Je haalt hier twee concepten door elkaar. De parent/child relaties van widgets is een relatie tussen objecten, niet tussen classes. Polymorfisme in OO is wel een relatie tussen classes.
Ik haal niets door elkaar. Widgets zien als objecten maakt de parent-child-relatie logisch, net als overal referenties naar hetzelfde object hebben.
Rust makes certain idioms easy, but does not adapt well to the traditional object oriented model of the world, which at heart is a big wad of shared mutable state, where interacting objects all have references to each other.
https://raphlinus.github....2019/10/31/rust-2020.html

[Reactie gewijzigd door 84hannes op 23 januari 2020 10:30]

Wij van Wc-eend adviseren Wc-eend.
Dat vind ik een beetje kort door de bocht. Deze gast is niet Rust gaan gebruiken omdat Mozilla hem er geld voor geeft: hij, en prodrive, zijn het gaan gebruiken omdat ze er voordelen in zagen. Mozilla zelf natuurlijk ook, maar daar erken ik een bias omdat zij de ontwikkeling sterk beïnvloeden.
Even realiseren dat Prodrive als bedrijf en de representatie van Prodrive hier wel verschillen. Het zal geen bedrijfspolicy zijn maar wel mogelijk indien de juiste combinatie van team, project manager en indien van toepassing, de klant.

Source: worked there.
Maar dat is toch precies waar het om gaat? Iemand die kan vertellen waar en wanneer het de juiste keus is. Het praatje heet niet “Rust is altijd beter dan C++”.
Bedrijfspolicy is (source: still works there) om altijd de juiste tool te gebruiken voor de job. Vaak is dat nog steeds cpp vanwege een hele hoop legacy in bestaande codebases. Maar als je de mogelijkheid hebt iets nieuws te bouwen dan is het plaatje opeens heel anders en worden alternatieven als Rust ineens interessanter.

We proberen bij Prodrive juist nieuwe ontwikkelingen niet af te houden omdat het eng is, zo hebben we bij webdev Elm geintroduceerd, iOS stuff schrijven we in Swift, backends in F#, tuurlijk is er een hoop legacy maar het is mooi om de voordelen van nieuwe ontwikkelingen te zien en kunnen gebruiken.
Oeh dat is wel cool! Jammer dat ik vooral op legacy projecten zat :< En klopt, dat motto blijft gelukkig bij de interessante bedrijven in leven :)
Ik las tot de zin "Sinds 2015 is hij betrokken bij het project en de community erachter.". Daarna scheerde ik erdoorheen, want bias. En toen zag ik "Koop je ticket", dus ik dacht misschien staat er nog wat interessants bij de comments :+

Blij dat ik dat gedaan heb.
Hoe ga je vanuit een positie van kennis een masterclass geven zonder dat je er daadwerkelijk kennis van hebt? Het lijkt me logisch dat Carton ofwel veel ervaring heeft met rust of wel onderdeel uit maakt van de community of het iig op de voet volgt, hoe ga je anders iets er van leren :>

Het lijkt alsof hij het "verkoopt" maar het lijkt mij dat hij er oprecht erg enthousiast over is dus komt het van nature over zoals het doet
Dit, daarnaast is het gewoon een advertentie. Ik had gehoopt op een inhoudelijk artikel viel me daarna tegen.
En als ik dan zie wie deze meneer Carton vertegenwoordigd, lijkt dit meer op een veredeld marketing praatje.
Ja, dit lijkt eigenlijk op een betaalde advertentie. Zeker met die link onderin waar je je mee kunt inschrijven voor de dev summit. |:(
De dev summit is van tweakers zelf, he. Natuurlijk is dit gewoon reclame voor hun eigen event. De "auteur" is ook Tweakers Events.

[Reactie gewijzigd door .oisyn op 21 januari 2020 15:22]

Het probleem is denk ik dat hier een advertentie is vormgegeven als een normaal artiekel. Ik weet niet of dat tegenwoordig nog legaal is zonder erbij te zeggen dat het om reklame gaat.
Hoezo :? Het is een .plan, natuurlijk gaat dat over tweakers zelf.
Rust is een van de Items op de summit. Wat zorgt ervoor dat Rust er op deze manier uitgelicht wordt? Zou tweakers een promo hebben gemaakt van de summit zelf dan zou ik een artikel verwachten waarin een soort status update wordt gegeven ("er zijn nog kaarten") en dat er een rondje langs de onderwerpen wordt gemaakt.

Dat dit hier niet gebeurt kan vragen oproepen. Misschien gaan we een reeks nieuws items zien over de summit met ook andere sprekers. Maar dat referentiekader is hebben we nu nog niet. Het lastige is dat met wat we wel weten we bijna niet mogen verwachten dat dit item geen bias heeft. Zo wordt de vorm een handicap voor de geboden informatie, niet in het belang van Rust. Een gedeelte van de mensen die begonnen te lezen diskwalificeren het verhaal omdat door de vorm de neutraliteit niet is gewaarborgd.

Los hiervan gun ik Rust alle aandacht die het waarschijnlijk best wel verdient.
Misschien gaan we een reeks nieuws items zien over de summit met ook andere sprekers.
Oh je bedoelt zoals deze:
plan: Dev Summit: Elsa Sotiriadis over biohacking als de volgende softwarerev...
plan: Dr. César Rodríguez-Rosario: "De quantum community heeft developers nodig"
plan: David Foster: ''We moeten leren wanneer we een robot een knuffel moeten...
:P

En nog allerlei andere .plans die aan de de summit zijn gewijd...

[Reactie gewijzigd door .oisyn op 21 januari 2020 20:34]

Oke, oke, duidelijk ;), ik heb tenminste nog de smoes dat ik zelf geen developer ben dat ik ze gemist ben.

Dat ze een reeks artikelen doen en via die onderwerpen de summit voor het voetlicht willen halen geeft wel het kader. Misschien dat door de links onderaan zo'n artikel toe te voegen het voor de lezers nog wat beter te interpreteren maakt. Out of the blue had ik toch ook iets van "wat is dit nu precies".
Rust zal best prima zijn, maar ik krijg nu voornamelijk een gekleurd beeld voorgeschoteld.
Dat is toch altijd het geval zodra je naar dit soort events gaat? En dat is ook niet zo erg want als het goed is ben je zelf de beste die kan beoordelen of Rust past bij jouw wensen en/of taken.

Die vergelijking met c++ is ook wel vervelend maar dat is in het algemeen wel zo vind ik. Ik weet niet hoe dat bij jullie is maar soms heb je gewoon niet veel te willen en zijn er externe factoren die bepalen of je wel of niet gebruik van iets kunt maken, en bijna nooit is de kwaliteit van een taal daarin doorslaggevend.
[...]


Dat is toch altijd het geval zodra je naar dit soort events gaat? En dat is ook niet zo erg want als het goed is ben je zelf de beste die kan beoordelen of Rust past bij jouw wensen en/of taken.
Plus we hebben het hier niet over het beste pak cornflakes of zo. Mensen die C++ of Rust (willen gaan) gebruiken hebben wel enige voorkennis en kunnen dus inderdaad prima beoordelingen maken.
In mijn beleving is c++ niet een functionele taal maar eerder een OO taal?
Het is multi-paradigm, net als C++, maar net als C++ is het vooral imperatief. Geen idee waar de auteur dat vandaan haalt :) @Romeowhite
Rust zal best prima zijn, maar ik krijg nu voornamelijk een gekleurd beeld voorgeschoteld
Eens. Iets dat ik overigens wel vaker merk vanuit de Rust community, ze zijn er als de kippen bij om het vooral als beter dan C++ af te schilderen. Imho hebben beide talen zo hun voor- en nadelen (en heeft C++ vooral last van zijn eigen bagage, die Rust natuurlijk niet heeft)

[Reactie gewijzigd door .oisyn op 21 januari 2020 14:36]

Het is ook niet de eerste taal die claimt "een betere C++" te zijn; datzelfde idee was ook de basis voor D. D stamt uit 2001, terwijl Rust 9 jaar nieuwer is. Je ziet overigens bij beide talen dat ze óók een legacy ontwikkelen, terwijl ze beiden juist claimden dat ze zich daarin onderscheiden van de C legacy in C++.
Ze claimen zelf ook niet de taal te zijn die alle anderen overbodig maakt. Ze hopen dat toekomstige talen zich door Rust laten inspireren. Je moet toegeven, de benadering voor geheugenbeheer van Rust is uniek en heel interessant.
Nou ja, het borduurt natuurlijk voort op move-only types uit C++. Het is alleen de default, ipv de copy zoals in traditionele talen.
Klopt, er is niets dat je met Rust kan doen dat echt niet kan met C++. Maar ja, er is ook niets dat met C niet kan, of met assembly. Het gaat er in dit geval meer om hoe makkelijk het is om fout te doen. Dat het met C/C++ makkelijk is geheugenbeheer verkeerd te doen mag geen verrassing zijn. Bij Rust kun je dat alleen expliciet fout doen, dat lijkt me wel relevant.
edit:
Ik heb er nog even over nagedacht

De borrow checker is echt wel krachtiger dan wat C++ kán. Zo controleert rust of je geen referenties naar elementen uit een vector hebt vóórdat je de vector zelf mag manipuleren. Het omdraaien van twee regels code kan namelijk al tot een bug leiden.

Rust heeft een iets steilere leercurve omdat je vanaf het begin alles veilig moet doen. In C++ leer je eerst hoe het makkelijk kan en pas daarna, als je echt zin hebt, hoe het veilig kan. Het later toevoegen van move only types is dus een hele andere benadering en ik denk dat we allebei kunnen raden wat de meest veilige benadering is.

[Reactie gewijzigd door 84hannes op 22 januari 2020 07:31]

Ik denk omdat de makers van Rust de taal op die manier willen positioneren. C++ is de voertaal in de meeste embedded applicaties en Rust profileert zich als een veiliger alternatief: https://rust-embedded.github.io/book/

https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

[Reactie gewijzigd door Neophyte808 op 21 januari 2020 14:34]

Zelfs al zou Rust beter zijn dan C++ (ik kan daar niet over oordelen want ik ken Rust niet) dan is er nog altijd het feit dat er zeeën van projecten zijn die nu in C++ geschreven zijn. Deze hoeveelheid legacy code zal kennis en gebruik van C++ nog lang in leven houden. Omschakelen zal voor velen (financieel) lastig zijn.

[Reactie gewijzigd door MaestroMaus op 21 januari 2020 22:51]

Financieel mag geen kwestie zijn. Op de langere termijn moet een beetje financieel savvy developer toch wel kunnen uitleggen aan de accountant dat kosten over langere termijn hoger zijn in termen van gemiste kansen, hogere developers kosten, minder onderhoudbare codebase (dus verlaagde productiviteit)...etc.
Dan heb ik hier een reality-check voor je: veel van de Nederlandse banken draaien nog steeds oude Kobol/Fortran software die in het verleden gemaakt is. En ze zijn lang niet de enige. Het spijt me, maar IT wordt in het bedrijfsleven nu eenmaal niet zo serieus genomen als je denkt. Bovendien worden de meeste managers afgerekend op maand/kwartaal/jaarbasis en dus niet op goede langetermijnoplossingen. Een grote investering doen om ver in de toekomst "iets te krijgen wat je nu al hebt, maar dan wat beter" doen ze ongeveer even graag als tanden laten trekken want dat verkoopt niet bij aandeelhouders en zorgt voor een grote kostenpost.

[Reactie gewijzigd door MaestroMaus op 21 januari 2020 17:21]

In aanvulling op @MaestroMaus vind ik dat Rust zich ook nog niet echt bewezen heeft. Ik ken de theorie en geloof de theorie. Niet alleen ik, ook bij Microsoft en Google wordt die theorie met interesse bekeken. Maar totdat is aangetoond dat, bijvoorbeeld, Firefox Quantum significant minder (geheugen-)bugs heeft dan Chrome (en afgeleiden) blijft het in mijn ogen een theorie. Daarbij is nog niet aannemelijk dat Rust-applicaties over 10 jaar nog steeds onderhoudbaar zijn, terwijl ik er aardig wat geld op durf te zetten dat er over 10 jaar nog een actuele C++ compiler is voor mijn OS, en ontwikkelaars te vinden zijn die daarmee om kunnen gaan.
Rust is absoluut mooi spul. Zeker als je nu veel in C++ doet, is het de moeite waard om er eens naar te kijken.

Maar Rust vereist wel een hele andere mindset dan bv Java. Dus voor bedrijven/programmeurs die nu met Java/C#/Python werken is het nog steeds interessant om naar te kijken maar overstappen zal waarschijnlijk niet zo aantrekkelijk zijn (lees: te veel moeite kosten).

Ik zou willen dat sommige features hun weg naar Java vinden (zoals (default) immutability en type inferencing) maar dat zal erg lastig worden ivm backwards compatibility.
Ik zou willen dat sommige features hun weg naar Java vinden (zoals (default) immutability en type inferencing)
Enter Kotlin: volledig backwards compatible met Java, maar met mooie features die vanwege backwards compatibility nooit in Java gaan komen.
Java heeft al aardig wat type inference tegenwoordig. Al best lang in Generics, maar sinds 8 ook in Lambda expressies, en sinds Java 10 heb je ook Local Variable Type Inference, zodat je 'var' kan gebruiken...

Default immutability zal denk ik niet snel komen. Maar het houd je niet tegen om Immutable Objects te maken.

Java ontwikkeld zich de afgelopen jaren ook een stuk sneller, met elke 6 maanden een nieuwe versie -> https://www.rushis.com/java-release-model/

Maar ook hier spreekt een Java engineer, dus wij van wc-eend...
Ik vind de Rust syntax lelijk en moeilijk te volgen.

Vroeger had je onleesbare C code wedstrijden en ik denk dat Rust hier gaat winnen. Waarom zou je zaken moeilijk maken als het makkelijk kan? Ik snap dat niet.
Quote uit het artikel:
onder meer op Stack Overflow waar Rust al vier jaar op rij de populairste taal is.

Really? 8)7 Wat een leugen! :o Kijk maar eens op https://stackoverflow.com/tags

De huidige top 3:
  • Javascript: 1933645
  • Java: 1627182
  • C#: 1374739
(vele pagina's verder)
  • Rust: 14811
Niet qua aantal vragen op Stack Overflow, maar wat mensen zelf aangeven als hun "most loved" language in de SO Developer Survey. Daar staat Rust namelijk al wel 4 jaar op de eerste plek.

"For the fourth year in a row, Rust is the most loved programming language among our respondents, followed close behind by Python, the fastest-growing major language today."
Zie: https://insights.stackove...-loved-dreaded-and-wanted

[Reactie gewijzigd door IkBenTweaker op 21 januari 2020 19:30]

Populair betekent: graag gebruiken. Bijvoorbeeld in de file staan doen heel veel mensen heel vaak heel lang, maar dat is niet populair. Sharepoint wordt door heel veel mensen gebruikt, maar is niet populair.
Most Loved, Dreaded, and Wanted Languages

Loved
1. Rust, 83.5%
2. Python, 73.1%
3. TypeScript, 73.1%
https://insights.stackoverflow.com/survey/2019

Je hebt gelijk dat stackoverflow ‘popular’ verward met ‘veelgebruikt’.
Een andere leuke taal om in de gaten te houden komende tijd is Zig. Deze probeert dezelfde soort problemen op te lossen als Rust.

https://www.youtube.com/watch?v=Gv2I7qTux7g
https://github.com/ziglan...ready-CPP,-D,-and-Rust%3F
Meh, 'beter' dan C++. Zo'n titel is een instant skip. Net als al die hobbytaaltjes die 'faster dan C' willen zijn.
Een taal op zichzelf is waardeloos. Grote frameworks en libraries zijn wat een taal belangrijk maken.Use cases. Kotlin heeft Android. Python heeft Django en veel ML. Java en C# hebben gigantisch veel footprint bij grote bedrijven en superveel libraries. Javascript domineert de browser.

Alles van scratch maken in een nieuwe taal is veel te veel werk. Zo lang er geen framework of library is welke Rust apart zet zijn er weinig use-cases voor.
De grootste potentiële use case voor mij persoonlijk is Redox OS draaiend op ARM, POWER en RISC-V. Er zijn geen legacy code en applicaties en zoveel mogelijk is gebaseerd op Rust code. Het is wel mogelijk om legacy code te draaien door middel van relibc, maar dat mag nooit de primaire doelstelling zijn.

Natuurlijk staat het nog in de kinderschoenen, maar vorig jaar op FOSDEM heb ik enthousiast de presentatie over het proces van het porten naar Aarch64 gevolgd en ook nog even met de ontwikkelaar zelf gesproken. Beetje bij beetje probeer ik de hiaten in mijn eigen kennis te vullen om er in de toekomst wellicht ook aan te kunnen werken en daar hoort het leren van Rust ook bij.
En nog een probleem voor nieuwe programmeertalen is het kip-ei probleem dat er weinig goede programmeurs zijn die thuis zijn in de nieuwe taal.

Als bedrijf ga je niet zomaar een belangrijk systeem in een nieuwe taal laten programmeren. Het is al zo moeilijk om echt goede software developers te vinden, zelfs voor de meest populaire programmeertalen zoals Java en C#. Ga je een systeem in nieuwe taal X bouwen dan maak je dat probleem van het vinden van goede ontwikkelaars die je software kunnen onderhouden nog veel erger maken...

Dus een nieuwe taal moet iets hebben wat tegen dat grote nadeel opweegt, anders is het als bedrijf niet verstandig om erin te duiken.
Idd, hoewel ik op mezelf Rust aan het leren ben, ken ik weinig bedrijven in NL die dit gebruiken. Ik vindt het zelf wel een fijne taal.

[Reactie gewijzigd door rjberg op 22 januari 2020 07:10]

Mee eens, ik heb ook wel eens met Rust gespeeld en het is best leuk.

Dat bedrijven niet zo snel zullen overstappen op een nieuwe taal voor hun business software betekent overigens niet dat je als individuele software developer niet naar andere talen moet kijken. Nieuwe programmeertalen leren is leuk en interessant en maakt je een betere software developer, zelfs voor de taal waar je dagelijks op het werk mee aan de slag bent.

Op het werk programmeer ik in Java maar de afgelopen jaren heb ik gespeeld met o.a. Scala, Kotlin, JavaScript, TypeScript, Go, Rust, C# en zelfs met Clojure (Lisp voor de JVM) en Haskell.
Ligt het aan mij, of is de titel “Vaak gevallen beter dan C++” raar Nederlands? Wordt er soms "In veel gevallen beter dan C++" bedoeld?
Ik vond het ook al een rare zin ja 🙂
Dat deugt niet natuurlijk, dit is geen fatsoenlijk Nederlands.
Ik vermoed dat het eerst 'In veel gevallen better dan...' was, maar de zin dan nét te lang was voor de view op de frontpage. Toen er dus 'Vaak beter dan...' van willen maken maar het woordje 'gevallen' vergeten weg te halen.

Aannames, aannames... :+
Vele in plaats van Vaak klinkt al beter
vaak gevallen is een pijnlijke zaak

Op dit item kan niet meer gereageerd worden.


Apple iPhone 11 Microsoft Xbox Series X LG OLED C9 Google Pixel 4 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True