Mozilla kondigt 1.0-versie van Rust-programmeertaal aan

Mozilla Research heeft vrijdag de eerste stable release van Rust vrijgegeven. Deze recentste release van de programmeertaal betekent dat het ontwikkelteam de bestaande bibliotheek niet meer gaat veranderen. Dit betekent overigens niet dat de taal 'af' is.

Mozilla ontwikkelde Rust met drie doelen in het achterhoofd: veiligheid, snelheid en gelijktijdigheid. Mede door een moderne architectuur zou de taal geen last hebben van beveiligingsproblemen als buffer overflows. Ook zou Rust een veiliger geheugenbeheer hebben.

De afgelopen maanden experimenteerden de ontwikkelaars naar eigen zeggen flink met de mogelijkheden van Rust. Dit betekende dat bestaande projecten moeilijk te onderhouden waren. Inmiddels is de ontwikkeling van de taal in een rustiger vaarwater terechtgekomen; de taal en de standaardbibliotheek blijven nu in de basis hetzelfde.

Voor ervaren ontwikkelaars biedt Rust volgens de bedenkers minder kans op fouten, doordat de programmeertaal simpeler zou zijn dan andere, soortgelijke talen. Zo hoeven die ontwikkelaars minder tijd te stoppen in het debuggen van hun code. Minder ervaren ontwikkelaars zouden daarnaast de taal sneller oppakken en dus eerder complexe programma's kunnen schrijven.

Mozilla Research werkt intussen al flink door aan de doorontwikkeling van Rust, waarvan bètaversie 1.1 al is verschenen. De nightly builds zijn uitgerust met verbeteringen die het compileren van de code moeten versnellen. Ook beschikken ze over nieuwe api's en features.

Iedere zes weken verschijnt er een nieuwe release van Rust. Voor het downloaden van dependencies en het bouwen van een build kunnen ontwikkelaars de Cargo-pakketbeheerder gebruiken. Om dependencies van anderen te vinden, biedt Mozilla Research de repository Crates.io aan.

Reacties (43)

Rust positioneert zichzelf als een low-level taal en ziet zich graag als vervanger voor C op platformen zoals RPI etc. Combinatie van C-like performance en een feeling van high level talen zijn key features.

Voor wie het wil proberen: http://rustbyexample.com/

Goed dat ik dit hier kan lezen. In het artikel mis ik wat diepgang. Ik dacht aanvankelijk dat het weer een iteratie van een JavaScript library zou zijn omdat Mozilla toch wel snel doet denken aan Firefox en "het web". Bedankt voor je comment.

Ik ben overigens benieuwd hoe dit werkt. Als een OS een code niet native ondersteunt, dan veronderstel ik dat het eerst gecompileerd moet worden? Ietwat off-topic, maar kan iemand me zeggen welke programmeertalen Windows en Linux native kan uitvoeren?

Windows en Linux ondersteunen native alleen machine code waarbij ieder platform zijn eigen container heeft. Windows gebruikt het PE formaat en Linux het ELF formaat. Linux heeft voor niet machine code (programmeren talen dus) en extra optie van een hash-bang regel. Deze geeft aan met welk programma (interpreter/VM) het bestand moet worden uitgevoerd. Windows kent hiervoor bestandextensie associatie.

In het kort betekent dit dat je een programmeertaal welke dan ook moet installeren om het te gebruiken of dat de programmacode moet worden omgezet naar machine code (code die de CPU direct kan uitvoeren) in het juiste container formaat.

Helder, jammer dat ik op T.net naar de reacties moet voor deze nogal belangrijke info.

offtopic:
gelukkig zijn er Tweakers als jij

Ah, ik dacht dat Rust een soort naäper van TypeScript was!

Rust positioneert zichzelf als een low-level taal en ziet zich graag als vervanger voor C op platformen zoals RPI etc.

Inderdaad, zie deze presentatie van Pycon over wat dat betekent, ook voor performance: http://youtube.com/watch?v=3CwJ0MH-4MA

De volgende is ook wel aardig, video van de 1.0 release party: https://air.mozilla.org/rust-release-party

Voor meer algemene info over Rust zie deze pagina: https://rust.zeef.com/harris.brakmic

Veel discussie over de ontwikkeling van deze taal is ook via de Reddit community gegaan:
http://reddit.com/r/rust

Ik ben erg enthousiast over deze taal die garanties die we kennen van functionele talen zoals Agda en Haskell probeert te brengen naar het imperatieve domein, en dan ook nog het gevaarlijke terrein van system programming.

Het bijbehorende boektutorial werk van Steve Klabnik zit héél veel werk in, en echt hartstikke hulde daarvoor:
http://doc.rust-lang.org/book/index.html

Ziet er leuk uit, maar waarom dan geen python? Dat wordt namelijk al vaak gebruikt en is erg eenvoudig want je hebt geen gekke "classes", is gratis en volgens mij ook best snel.

Bovendien kan je python zo uitgebreid maken als je wilt, door meerdere packages/libraries/modules (of hoe je ze ook wilt noemen) te installeren.

[Reactie gewijzigd door Frozen op 15 mei 2015 21:55]

Omdat Python verder van de hardware af zit dan Rust en daarmee een ander doel heeft.

Python past wat dat betreft in het rijtje: Ruby, Java, C#, etc. Deze worden niet gecompileerd naar machine-code, maar in plaats daarvan naar soort universele "hoge" tussenvorm die makkelijk te interpreteren is door verschillende systemen. Daarom zijn deze talen vaak te gebruiken op verschillende hardware/processoren en operating systems. Deze zijn vaak ook makkelijker in gebruik voor de programmeur. De keerzijde is dat ze langzamer zijn, omdat ze minder geoptimaliseerd (kunnen) worden voor de hardware waar ze uiteindelijk op draaien. Direct hardware aansturen (zonder OS, API of driver als tussenlaag) is hiermee meestal ook niet mogelijk, omdat daarvoor directe controle over geheugen en instructies nodig is.

Pascal, Golang, Rust, C en C++ worden gecompileerd naar machinecode, dus specifiek naar de processor instructieset van de hardware waar de code uiteindelijk op draait. Deze talen zijn meestal "lager" dan niet-gecompileerde talen; de gebruiker is verantwoordelijk voor het juiste gebruik van geheugen, instructies en op de juiste manier aanspreken van hardware. Voordeel: het is zowel voor de programmeur als voor de compiler veel beter te optimaliseren (dus snellere code). Nadeel: het is wat tijdrovender programmeren en debuggen. Memory leaks zijn bijvoorbeeld erg lastig te vinden en kunnen veel tijd kosten, terwijl dit een probleem is dat bij hogere talen niet van toepassing is.

Conclusie: er is niet zoiets als een "slechtere" of "betere" taal. Welke taal beter of slechter is hangt af van: de smaak/mening van de programmeur voor wat betreft syntax, de toepassing, hoe snel het af moet VS hoe efficient de code moet zijn, op welke hardware het draait (embedded op batterij of een dikke vette server in een serverfarm?), etc.

Overigens kun je voor zover ik weet hogere talen als Python vaak prima mixen met lagere gecompileerde stukjes code die dan door Python aangeroepen worden (of omgekeerd), dus dan heb je nog veel meer smaakjes

[Reactie gewijzigd door GeoBeo op 15 mei 2015 22:14]

Python past wat dat betreft in het rijtje: Ruby, Java, C#, etc. Deze worden niet gecompileerd naar machine-code, maar in plaats daarvan naar soort universele "hoge" tussenvorm die makkelijk te interpreteren is door verschillende systemen.

Java en C# worden door een Just-In-Time compiler nog altijd omgezet naar native instructies vooraleer ze uitgevoerd worden. Dit is bij Python (en Ruby?) niet het geval. Python staat dus nog een trede hoger in jouw lijstje aangezien die standaard geïnterpreteerd wordt (misschien met uitzondering van PyPy).

De keerzijde is dat ze langzamer zijn, omdat ze minder geoptimaliseerd (kunnen) worden voor de hardware waar ze uiteindelijk op draaien. Direct hardware aansturen (zonder OS, API of driver als tussenlaag) is hiermee meestal ook niet mogelijk, omdat daarvoor directe controle over geheugen en instructies nodig is.

Dat is een fabeltje van jewelste. C# en Java code kunnen even snel of sneller zijn dan C/C++ doordat de compiler run-time informatie kan meenemen om te optimaliseren in de JIT-compiler. Profile-guided optimisation is in C/C++ voor grote codebases met veel normale use-cases bijna ondoenbaar.

Alvast in C# kan H/W access ook gewoon via de standaard OS API's via unsafe calls. Hell, Microsoft had zelfs een C#-based kernel prototype. Geen idee echter hoe Java (JNI?) en Ruby (ruby-mmap en ioctl ?)dit kunnen.

Voordeel: het is zowel voor de programmeur als voor de compiler veel beter te optimaliseren (dus snellere code).

De optimalisaties die je als developer kan doen zijn in al die talen hetzelfde: memory, memory en memory. We zijn al lang voorbij het punt waarop instructies tellen relevant is voor de snelheid van een programma (muv exotische zeer rekenintensieve taken).
Optimaliseren komt zowat altijd neer op het slim omgaan met memory access en de cache hierarchie. Dat geldt voor high-level talen even hard als voor low-level talen.

Nadeel: het is wat tijdrovender programmeren en debuggen. Memory leaks zijn bijvoorbeeld erg lastig te vinden en kunnen veel tijd kosten, terwijl dit een probleem is dat bij hogere talen niet van toepassing is.

Je kan in alvast in C++ perfect memory-leak free code schrijven, als je de juiste constructs gebruikt. Je kan in Java, C#, python ook memory-"leaks" schrijven. Probeer maar eens een dictionary<string, data> op te vullen zonder ooit te legen...
Het hangt gewoon af van de developer, de taal is voor die generatie talen relevant in hoeveel tools je tot je beschikking hebt, maar dat is in de huidige tijden echt het probleem niet meer.
Rust lijkt me hier echt een nieuwkomer in qua concepten voor memory safety.

[Reactie gewijzigd door H!GHGuY op 16 mei 2015 08:54]

Java en C# worden door een Just-In-Time compiler nog altijd omgezet naar native instructies vooraleer ze uitgevoerd worden. Dit is bij Python (en Ruby?) niet het geval. Python staat dus nog een trede hoger in jouw lijstje aangezien die standaard geïnterpreteerd wordt (misschien met uitzondering van PyPy).

Dit is bij Python PyPy in elk geval wel het geval, voor Ruby weet ik het niet:

Current PyPy versions are translated from RPython to C code and compiled. The PyPy JIT (short for "Just In Time") compiler is capable of turning Python code into machine code at run time.

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

En

Alvast in C# kan H/W access ook gewoon via de standaard OS API's via unsafe calls. Hell, Microsoft had zelfs een C#-based kernel prototype. Geen idee echter hoe Java (JNI?) en Ruby (ruby-mmap en ioctl ?)dit kunnen.

Klopt. Daarom schrijf ik ook dat direct hardware aansturen met hogere talen niet mogelijk is. Via een OS API of een library die weer gebruik maakt van de OS API kan dat natuurlijk wel. Je kunt dus bijvoorbeeld geen microcontroller firmware schrijven in C# (tenzij de fabrikant een C# lezer gebouwd heeft die het weer omzet naar C en/of machine code, dit is uiteraard meer moeite dan gewoon C/Assembly ondersteunen). Ook de Kernel/API zelf zal niet in een hoge taal geschreven zijn om diezelfde redenen. Mensen die zich bezig houden met het zoeken van exploits in runtime code zullen ook tools schrijven/gebruiken uit lage talen. En het perfecte on-topic voorbeeld: de Rust compiler zal ook in een lage taal geschreven zijn, omdat lage talen simpelweg dichter bij machine-code zitten en daarvoor dus beter geschikt zijn. JIT-compilers zullen ook (deels) in lage talen geschreven zijn... etc.

De optimalisaties die je als developer kan doen zijn in al die talen hetzelfde: memory, memory en memory.

Wat een onzin. Je kunt ook hele andere optimalisaties doen die het gebruik van het geheugen potentieel veel minder efficient maken. Of in lage talen geheugen bewust op bepaalde manieren gebruiken die in hogere talen onmogelijk zijn. Optimalisaties zijn niet in alle talen hetzelfde en bepaalde optimlisaties zijn in hogere talen zelfs inherent onmogelijk (en omgekeerd zoals je zelf aangeeft):
-- Optimalisatie naar minimale hoeveelheid instructies voor de processor.
-- Optimalisatie naar een bepaalde soort instructies (instructies die bijvoorbeeld een specifieke processor sneller kan afhandelen).
-- Optimalisatie naar een zo klein mogelijke gecompileerde machinecode (heel erg van belang bij embedded systemen).
-- Optimalisatie naar energie-zuinige processors of specifiek energie-zuinige instructies voor een processor (denk aan kleine batterij gevoede systemen).
-- Optimalisatie naar geheugen snelheid door bewust bepaalde zaken juist wel of niet in geheugen te laden (zaken die een hogere taal misschien niet automatisch direct in geheugen zet bijvoorbeeld).
-- Optimalisatie van geheugen snelheid door te spelen met snel stack (CPU cache) geheugen of relatief langzaam heap geheugen allocatie (bijvoorbeeld RAM geheugen).

Je kan in alvast in C++ perfect memory-leak free code schrijven, als je de juiste constructs gebruikt.

Ja duh, dat is mijn hele punt juist: dat moet je dan wel weten/op letten/goed doen. En dat kost natuurlijk moeite. En is dus lastiger. Je kunt ook prima heel snel bug-free direct machine-code schrijven als je maar goed op let en als je maar super-man bent die machine-code snapt.

Je kan in alvast in C++ perfect memory-leak free code schrijven, als je de juiste constructs gebruikt. Je kan in Java, C#, python ook memory-"leaks" schrijven. Probeer maar eens een dictionary<string, data> op te vullen zonder ooit te legen...

Een memory leak waarbij je geheugen vult dat je gereserveerd hebt (het voorbeeld dat je noemt) is niet echt een problematische memory leak, meer een ordinaire bug. Een echte memory-leak die je in C bijvoorbeeld kunt maken (die je helemaal niet in hogere talen kunt maken) is er eentje waarbij je, al dan niet per ongeluk geheugen adresseert buiten hetgeen je in je programma gereserveerd hebt voor adressering. Het kan dan dus zijn dat je gereserveerd geheugen uit je eigen programma (of zelfs andere programmas) op onvoorspelbare manieren manipuleert zonder daar controle over te hebben, wat hele rare bugs tot gevolg heeft waarbij de symptomen totaal geen hint geven van wat je waar in je code fout hebt gedaan. Zo kan een symptoom van een memory leak bijvoorbeeld zijn dat er iets raars gebeurt wanneer je op een knop drukt, terwijl de memory leak die hiervoor zorgt 1000 regels eerder staat en helemaal niets met knoppen/events/de betreffende functie/de betreffende klasse te maken heeft.

[Reactie gewijzigd door GeoBeo op 16 mei 2015 11:58]

Klopt. Daarom schrijf ik ook dat direct hardware aansturen met hogere talen niet mogelijk is.

Wat is er niet 'direct' aan het gebruik van memory mapped I/O?
Het is trouwens wel mogelijk (uiteindelijk is alles machinecode), alleen doet niemand het omdat het weinig zin heeft en de moeite groter is dan hetgeen je ervoor kan terugkrijgen.
Laten we het houden op dat het een semantische discussie is.

Zie trouwens: https://en.wikipedia.org/...ty_%28operating_system%29

Wat een onzin. Je kunt ook hele andere optimalisaties doen die het gebruik van het geheugen potentieel veel minder efficient maken.

Weet ik ook wel, maar jij haalde in je betoog aan dat het over snellere code ging.
Niet over code die minder geheugen gebruikte of bepaalde instructies nodig had, etc.

Ik zeg enkel dat performance optimisations over het algemeen op hetzelfde neerkomen: cache hierarchy. Zelfs SIMD is in hogere talen geen probleem meer.
Zie https://blogs.msdn.com/b/...-are-getting-married.aspx

Even overlopen:

-- Optimalisatie naar minimale hoeveelheid instructies voor de processor.
-- Optimalisatie naar een zo klein mogelijke gecompileerde machinecode (heel erg van belang bij embedded systemen).

Compiler switch. Typisch zinloos op hogere talen. Je binary 100KB kleinere maken en dan de run-time libraries van enkele MB inladen ... In de Linux kernel wordt -Os trouwens nauwelijks gebruikt omdat het meestal idiote code genereert.
Zie https://lwn.net/Articles/534735/

-- Optimalisatie naar een bepaalde soort instructies (instructies die bijvoorbeeld een specifieke processor sneller kan afhandelen).

Beschikbaar op higher level en lower level talen. Zie link van hierboven.

-- Optimalisatie naar energie-zuinige processors of specifiek energie-zuinige instructies voor een processor (denk aan kleine batterij gevoede systemen).

Zaken zoals ARM Thumb instructies zijn ook gewoon een compiler switch.

-- Optimalisatie naar geheugen snelheid door bewust bepaalde zaken juist wel of niet in geheugen te laden (zaken die een hogere taal misschien niet automatisch direct in geheugen zet bijvoorbeeld).

Ik denk dat je bedoelt op prefetch instructies? Deze zijn echt je weapon of last resort. Ze zijn zeer delicaat en je past ze best enkel toe al je alle andere memory-bound optimalisaties al gehad hebt. (met uitzondering van cache evict en cacheline clear). Zulke code kan bij de minste aanpassing (of zelfs compiler update) averechts uitpakken en je code trager maken.
Hogere talen hebben hier zelfs een voordeel, ze kunnen in de JIT compiler dit soort dependencies beter detecteren. Of ze echter prefetches genereren kon ik niet meteen vinden.

-- Optimalisatie van geheugen snelheid door te spelen met snel stack (CPU cache) geheugen of relatief langzaam heap geheugen allocatie (bijvoorbeeld RAM geheugen).

Ik denk dat je hier wel weet wat er achter zit (stack geheugen is door het continu gebruik meestal aanwezig in de caches en genereert dus minder cache misses), terwijl een nieuwe allocatie cache-cold kan zijn - alleen druk je jezelf nogal dubbelzinnig uit... Natuurlijk is een heap allocatie zelf ook niet gratis aangezien de meeste standaard allocators locks hebben en een hoop boekhouding moeten doen (en daarbij zelf ook nog eens extra cache misses genereren).

Ja duh, dat is mijn hele punt juist: dat moet je dan wel weten/op letten/goed doen. En dat kost natuurlijk moeite. En is dus lastiger. Je kunt ook prima heel snel bug-free direct machine-code schrijven als je maar goed op let en als je maar super-man bent die machine-code snapt.

Weet ik wel, maar mijn punt was dat in huidige tijden de tools van bijvoorbeeld C++ goed genoeg zijn om dit soort fouten tot een minimum te houden.
Je zou zelfs kunnen zeggen dat Boost hier een klein mirakel heeft verricht.

Een memory leak waarbij je geheugen vult dat je gereserveerd hebt (het voorbeeld dat je noemt) is niet echt een problematische memory leak, meer een ordinaire bug.

En hoe is een memory leak geen ordinaire bug dan?

Een echte memory-leak die je in C bijvoorbeeld kunt maken (die je helemaal niet in hogere talen kunt maken) is er eentje waarbij je, al dan niet per ongeluk geheugen adresseert buiten hetgeen je in je programma gereserveerd hebt voor adressering.

Nee dat is een invalid reference (of in sommige gevallen een stale pointer access).
Dit is een memory leak:
[code]
void leak(void) {
int* leaking = malloc(400);
}
[/code]
Het geheugen waar leaking naar wees is op geen enkele (normale) manier nog te bereiken nadat de leak() functie afgelopen is.
Maar dat wist je (hopelijk) zelf ook wel.

In Managed talen kan je ook memory leaks hebben, zie:
https://msdn.microsoft.com/en-us/magazine/cc163491.aspx
Deze zijn soms even moeilijk te vinden als in een C/C++ applicatie.

Memory leaks zijn bijvoorbeeld erg lastig te vinden en kunnen veel tijd kosten, terwijl dit een probleem is dat bij hogere talen niet van toepassing is.

Memory leaks zijn wel degelijk van toepassing bij hogere talen, alleen bepaalde categorieën (unreferenced data) is geen probleem. Nu is dat toevallig wel normaliter zo'n beetje de meest lastigste categorie, maar toch.

Python's "eenvoudigheid" is een beetje een mes die aan beide kanten snijdt: kleine scriptjes schrijven is (vaak) simpel. Grotere, meer complexe programma's schrijven (en stabiel EN maintainable houden) is (in mijn ervaring) vaak een ramp.

Python lijkt dan wel snel op je moderne systeem, ik kan je verzekeren dat in situaties waar performance nodig is, het geen uitblinker is. (http://benchmarksgame.ali...p?lang=rust&lang2=python3)

Dat is wat kort door de bocht, want voor data analytics is het razend snel door encapsulation van fortran, c en door het gebruik van cython. Laatste is bijna native python maar dan typed; dat geeft vergeleken met c vaak maar 10% vertraging.
Voorbeeld van hoe snel het kan zijn:
http://nbviewer.ipython.o...marks/bench_groupby.ipynb

Je zegt het zelf al: als je externe talen integreert kan het snel zijn. Maar standaard Python is echt traag door al die dictionary accesses.

Grote, complexe programma's in Python schrijven is geen enkel probleem. Eigenlijk net zo min als in eender welke andere programmeertaal, met uitzondering van assembly (al zullen die-hard assembly-fans het daar vast ook niet mee eens zijn). Het valt of staat met het afspreken van goede coding standards en patronen en het toepassen van modularisatie.

Ik heb met een team enorme stukken software in elkaar gezet in Python die glashelder in elkaar zaten en waar nieuwkomers in het team ook vrijwel direct mee uit de voeten konden.

Qua prestaties is het echter vrij bedroevend, maar als je op de juiste punten C, C++ of Fortran-bindings inzet is het goed te doen. En zeker bibliotheken als Numpy (gebruikmakend van algoritmes in C en Fortran) en OpenCV maken het makkelijk om enorme hoeveelheden nummers op een goede snelheid te verwerken.

Echter, de overhead is wel vrij groot en zeker voor low-level performance-kritische zaken of embedded systemen is het niet echt geschikt.

[Reactie gewijzigd door MadEgg op 16 mei 2015 09:16]

Betekend dat je ook prima dus grote Javascript programma's kan schrijven(nodejs). Kun je ook op bepaalde kritische punten naar C++ binden. Maar ik denk dat dit juist de kracht is van Rust dat je beide hebt. Zonder te hoeven binden.

en volgens mij ook best snel.

Serieus??? Python is juist een van de meest trage mainstream programmeer talen. Alleen Ruby is nog net iets trager.

Als een ingewikkelde berekening (100% cpu bound) in C een seconde duurt, dan doet Python dat in ongeveer 100 seconden (ter vergelijking, C++ zou dat in ongeveer 1.5 seconden doen en Java in 2 seconden).

Je hebt je vergelijkingen een beetje fout. C++ zit op circa 0.98 seconde en Java op 1.15 - 1.25 seconde. Hoe kun je sneller dan C zijn, terwijl dat bijna assembly is? Dat komt omdat C té laks is met type safety. Dat heeft als gevolg dat er in C soms een enkele variabele mogelijk gewijzigd kan worden door een write naar een andere variabele, terwijl een typesafe taal kan bewijzen dat die andere variabele een verschillend type heeft en dus onafhankelijk is.

Inderdaad, in gevallen kan C++ inderdaad sneller zijn, en Java kan zelfs sneller zijn dan beide.

In Java kan een compiler (de JIT versie) b.v. bewijzen dat een variable z'n scope niet kan ontsnappen en een heap allocated object (altijd bij Java voor objects) stack allocated maken.

Daarnaast kan de JIT compiler runtime informatie gebruiken voor optimalisaties. Als een branch altijd genomen blijkt te worden, kan true de fast path worden. Een C/C++ compiler kan dat niet, die moet er van te voren eentje kiezen. Wel kun je optioneel nog je C/C++ code optimizen door het met echte test data te runnen, maar dan heb je wel optimized voor die data. Live kan dat weer (heel) anders zijn.

Het is dus inderdaad niet zo makkelijk als dat C > C++ > Java, maar het ligt meestal wel grofweg in de zelfde orde. Python, Ruby, PHP zijn in nagenoeg alle gevallen duidelijk een flink stuk trager.

Wat bedoel je met gekke classes in python?

Python staat object georienteerd programmeren toe :
http://www.tutorialspoint...ython_classes_objects.htm

Kan iemand mij vertellen waar deze taal zich vooral op richt? De laatste tijd komen er veel verschillende talen op Tweakers. Zo ging het onlangs ook al over Google Dart.

Ikzelf heb ervaring met HTML, CSS, JavaScropt en JQuery.... Ik ben dus vrij "noob" kwa diepgaande talen. Wat is het verschil nu tussen Google Dart en Rust? Waarvoor zou je deze taal het beste kunnen gebruiken? Web applicaties of juist andere dingen?

En waarom bieden deze talen een betere toevoeging dan bestaande talen zoals Ruby (beetje hipster op dit moment) o.i.d. Hiermee kan je toch ook webapplicaties maken?

Daarnaast zie ik op de website dat ik Rust moet installeren, moet een eventuele consument of bezoeker dit ook doen voordat ze mijn code kunnen laten uitvoeren?

[Reactie gewijzigd door Anoniem: 673024 op 15 mei 2015 21:55]

Het grootste verschil met de talen die jij hier noemt en Rust is dat Rust zich in eerste instantie helemaal niet richt op web development. Het kan wel, zo is crates.io de website genoemd in het artikel ook gemaakt in Rust, maar de tools zijn zo minimaal dat het niet rendabel is om in Rust een volledige website/webapplicatie te maken.

Waar Rust wel voor bedoeld is code schrijven die even snel is en even veel controle geeft als de taal C of C++. Waarom dan kiezen voor Rust? Rust is in tegenstelling tot die talen wel standaard 'memory safe'(dus je hoeft het opruimen van geheugen niet zelf te regelen). Dit doen ze op een manier dat de plaatsen waar het geheugen moet worden opgeruimd van te voren wordt achterhaald doormiddel van een techniek die 'borrowing' heet.

Daarnaast is de taal ook geschikt om op een veilige manier code parallel te draaien, één van de grotere uitdagingen in het programmeren in low-level talen.

Dit alles is door Mozilla bedacht voor het project Servo(een samenwerking van Samsung en Mozilla) om een web browser te maken die grote performance winsten haalt uit het parallel draaien van de rendering.

Dus binnenkort is Firefox en andere software van Mozilla helemaal geprogrammeerd in Rust? Zou wel een leuke push zijn voor Rust.

Tevens zie ik graag low level talen verschijnen die ook multiplatform ontwikkelen een tikkeltje makkelijker maken. Echter is dat een beetje tegenstrijdig aan low level talen zoals C en dergelijks maar toch. Zou mooi zijn.

Dus binnenkort is Firefox en andere software van Mozilla helemaal geprogrammeerd in Rust?

Ik wilde hier net niet te veel op in gaan, maar Servo is een Research project. Om precies te zijn is Servo alleen de web browser engine en heeft het helemaal geen interface. Het maken van een complete web browser engine is echter enorm veel werk en helemaal als het ook nog met technieken die voor het eerst worden gebruikt op dit vlak.

Op dit moment heeft Servo al 126K lijnen code en dit is heel weinig vergeleken met de bestaande engines(Blink: 700K, WebKit: 1.3M).

Daarnaast heeft Mozilla nog zo veel projecten die gewoon te groot zijn om zo maar even te herschrijven.

Tevens zie ik graag low level talen verschijnen die ook multiplatform ontwikkelen een tikkeltje makkelijker maken. Echter is dat een beetje tegenstrijdig aan low level talen zoals C en dergelijks maar toch. Zou mooi zijn.

Rust is gemaakt met de compiler infrastructuur die LLVM heet. Het doel van LLVM is om cross-compiling een stuk makkelijker te maken. Er bestaat echter ook al wel een C/C++ compiler die ook LLVM gebruikt genaamd clang, dus op dit gebied bied het niet veel meer.

Misschien wel interessant om te weten is dat Apple ontzettend in zet op LLVM. Dit omdat de hoofd van Apple's developer tools team ook de maker is van LLVM en clang. Op dit moment gebruikt Apple het bijvoorbeeld voor compilen van Objective-C en Swift.

Dus het is in principe ook mogelijk om Rust code te maken die je kan draaien op iOS, maar omdat er nog geen tools zijn gemaakt om ook echt user interfaces te maken in Rust is dit nog totaal niet handig.

Duidelijk, hartelijk dank.

Ik ben het zelf ook moeten gaan opzoeken maar Rust heeft niet veel met websites te maken. Rust wordt als vervanger voor C++ gezien. Een gecompileerde taal die ook voor low level toepassingen kan gebruikt worden (drivers...). Het is dus niet bedoeld om de code even in iemand z'n browser uit te voeren.

Dus hoewel je met Mozilla direct aan een webtaal zou denken, zijn ze blijkbaar begonnen met Rust omdat hun programma's die in C++ zijn geschreven te veel beveiligingslekken geven door de gebreken in C++.

Ze willen eigenlijk zowat de flexibiliteit/toegankelijkheid van Python combineren met de snelheid van een gecompileerde taal, én dan ook nog eens veilig voor geheugenleaks en andere veiligheidsproblemen. Een ideale combinatie natuurlijk, dus ben benieuwd of dat volledig gelukt is aangezien er waarschijnlijk al voorgangers hetzelfde geprobeerd hebben.

[Reactie gewijzigd door Thmz159 op 15 mei 2015 22:24]

Ik moet eerlijk zeggen dat ik het idee eigenlijk geweldig vind. Maar een nieuwe taal aan de man brengen is nogal lastig. Als je kijkt hoe oud de gevestigde talen zijn hedendaags. Dan kom je daar niet zomaar even tussen. Javascript wordt niet zomaar even weggeschopt, in plaats daarvan optimaliseren ze de VM en pakken ze de taal langzaam aan.
Ook python heeft last van dat niemand overstapt naar Python 3. Omdat oude code allemaal in Python 2.x is geschreven. Het moet echt grote voordelen bieden voordat mensen overstappen.

Hartelijk dank, goed om te weten.

Rust wordt gecompiled naar executables. De verbruiker dient, mits de broncode naar het correcte platform gecompiled werd, geen runtimes of software te installeren. De programmeur die zijn broncode wil compilen wel.

Er is zeker een plek voor een low-level compiled taal met ondersteuning voor moderne concepten, zoals OO, generics en lambda's. C++ is het bewijs ervan. Je kunt C++ verwijten dat het teveel concessies doet aan backwards compatibility met C. Dat is de aanleiding voor de ontwikkeling van D. D is al een paar jaar oud, en heeft een zeer volwassen compiler.

Het verbaast me dan ook enigzins dat Mozilla gekozen heeft voor een eigen taal. Het ontwikkelen van een serieuze taal, met een serieuze compiler is hard werk. Maar D heeft het voordeel dat Walter Bright en Andrei Alexandrescu samenwerken, twee erkende genieën. Walter heeft eigenhandig C++ compilers geschreven, en Andrei is een expert op het gebied van software bibliotheken. Waarom Mozilla dit links laat liggen ontgaat me; ze hebben niemand op dat nivo.

Ooit gemerkt dat elk techbedrijf zijn eigen programmeertaal hanteert. MS heeft .NET, Apple objective C, Oracle en IBM doen aardig wat met Java, Google is lekker op weg met Python en Go. Facebook is aan de haal met PHP. Mozilla wil waarschijnlijk van betekenis blijven. Op javascript alleen gaan ze het niet redden.

PHP en .net zijn geen programmeertalen. PHP is een scripttaal en .Net is een framework platform welke bibliotheken en applicaties geschreven in verschillende programmeertalen makkelijker laat samenwerken. .Net is geschreven met de programmeertaal C# .

Javascript is overigens zoals de naam al zegt ook geen programmeertaal maar een scripttaal.

Facebook heeft dus een VM geschreven voor PHP. Met .NET bedoelde ik de MS talen zoals C# en Visual Basic. Ze gebruiken allemaal dezelfde VM als ik mij niet vergis.

Een lijst met prioriteiten is hier te vinden.

Per 6 week zal er een nieuwe (beta)versie gereleased worden. Na een aantal betareleases volgt dan een stable release.

Als Rust C++ moet opvolgen of vervangen, dan heeft Rust al verloren als het aan mij ligt.
De syntax lijkt alsof het geschreven is door iemand die enkel scripttalen heeft gezien.

• Je moet in de comments zetten of de functie iets returnt, of de body van de functie lezen.
• Dynamic / Duck typing, oftewel je moet boven iedere variable zetten wat voor data het is bedoeld en bereid je voor op een hoop bugs die je bij C++ normaal vindt tijdens het compileren. (let zegt niet zoveel over de variable, is het wel?)

Vraag me niet hoe je hier snel en veilige code uit maakt. Alles gebeurd hier net zo hackish als andere scripttalen.

[Reactie gewijzigd door RoestVrijStaal op 18 mei 2015 00:49]

Klopt eigenlijk bar weinig van wat je hier zegt.

Rust is statically typed, i.e. alle variabelen hebben een vast type. Er is ook absoluut geen sprake van duck typing. Ook geen garbage collection trouwens, al zei je daar niks over.

Wel kan je in veel gevallen de expliciete type declaraties weglaten, maar alleen als de compiler zelf met 100% zekerheid kan achterhalen welk type een variabele heeft. Over het algemeen moet je dus gewoon de argument en return types van een functie specificeren, maar kan je binnen een functie meestal de types weglaten als je dat fijn vindt.

Rust doet enorm hard zijn best om de compiler je zo veel mogelijk werk uit handen te laten nemen, maar gaat niet verder dan dat. Een van de belangrijkste doelstellingen van de taal is om nul extra runtime overhead te hebben t.o.v C.

[Reactie gewijzigd door doppelklick op 18 mei 2015 14:15]

Klopt eigenlijk bar weinig van wat je hier zegt.

Rust is statically typed, i.e. alle variabelen hebben een vast type. Er is ook absoluut geen sprake van duck typing. Ook geen garbage collection trouwens, al zei je daar niks over.

In de voorbeelden die ik zie in http://rustbyexample.com/ zie ik anders geen definities van variabelen waarbij ik direct weet welk type de variabele is.

Ik zie geen
[code]
int x = 2;
int y = 4;
int z = x*y;
[/code]

[code]
let x = 2;
let y = 4;
let mut z = x*y;
[/code]

Oftewel:
[code]
void* x = 2;
void* y = 4;
void* z = x*y;
[/code]

Oftewel bij Rust zou x, y of z van alles kunnen zijn, althans zo leest het wel voor iemand die onbekend is met de code.

Wel kan je in veel gevallen de expliciete type declaraties weglaten, maar alleen als de compiler zelf met 100% zekerheid kan achterhalen welk type een variabele heeft. Over het algemeen moet je dus gewoon de argument en return types van een functie specificeren, maar kan je binnen een functie meestal de types weglaten als je dat fijn vindt.

Rust doet enorm hard zijn best om de compiler je zo veel mogelijk werk uit handen te laten nemen, maar gaat niet verder dan dat. Een van de belangrijkste doelstellingen van de taal is om nul extra runtime overhead te hebben t.o.v C.

Ik heb zo'n idee dat het compileren langer duurt dan bij C of C++. En dat je net als bij dynamische talen moet rekening houden als je strings in combinatie met floating point values of integers gebruikt. Of sowieso het combineren van doubles en integers.

Het gaat erom dat als je in teams werkt (en dat is tegenwoordig geen zeldzaamheid), er meer apart gedocumenteerd moet worden welk datatype op welke variable van toepassing is. Of met try-&-error achterhalen. Self-documenting code wat C en C++ (en anderen) meer doen, heeft dan toch de voorkeur.

Je kan zoveel declaraties er in zetten als je zelf wil. Bijv "let x = 2;" is hetzelfde als "let x:i32 = 2", omdat de waarde "2" standaard het type i32 heeft.

Zoals bij elke taal moet je wel even de type conversion regels kennen (er is echter geen smerige autoconversion met strings). En C++ heeft ook "auto" tegenwoordig trouwens.

Ik begrijp het als je de voorkeur hebt voor meer verbose talen als Java, maar Rust is ongeveer zo ver verwijderd van een scriptingtaal als maar kan. Het is tenslotte de taal die door Mozilla's meest briljante C++ programmeurs ontworpen is om een nieuwe browserengine in te schrijven, wat niet bepaald een klein project is.

De compiler is nog wel wat traag, maar het is pas versie 1.0. Er is in compile snelheid nog nauwelijks werk gestoken. De foutmeldingen die hij geeft zijn echter wel zinvol, in tegenstelling tot de pagina's aan templatesoep die een C++ compiler nog wel eens wil produceren.

Als ik dit zie lijkt mij dit LUA maar dan als programmeer taal. Ik heb veel zomervakanties met LUA gewerkt met Computercraft. Het lijkt mij interessant om me hier eens in te verdiepen.

Zoals teddycoen een kwartiertje na jouw vraag uitlegt, is Rust een taal voor software die gecompileerd gedistribueerd wordt.

LUA code wordt op de computer van de gebruiker op het moment dat het nodig is, omgezet naar byte code en dan in een virtuele machine uitgevoerd.

Wellicht dat de syntax en woorden van LUA voor jou overeenkomsten vertonen met Rust, het doel van de taal is anders.

[Reactie gewijzigd door djwice op 17 mei 2015 00:22]

Het zou mooi zijn als er een taal zou zijn die beide zou kunnen. Dus en gecompileerd gedistribueerd en als interpreter. Dat zou fijn zijn voor developer en heb je de keuze om snelheid te kiezen of meer richting multiplatform.
Er zijn veel mensen die zeggen dat je niet 1 taal voor alles kan maken. Ik persoonlijk vind dat onzin. Ze gaan dan weer vergelijken met hamer en zaag, terwijl een programmeer taal heel iets anders is dan een fysiek iets. Je kunt namelijk met code bijvoorbeeld onmogelijke filters maken met signal processing. Welke met fysieke componenten zoals condensators en spoelen onmogelijk zijn.