Stichting achter programmeertaal Rust is van start gegaan

De Rust Foundation is officieel van start gegaan. De stichting gaat zich richten op het doorontwikkelen van de programmeertaal Rust. Dinsdag vindt de eerste bestuursvergadering plaats, waar leden van grote techbedrijven aan deelnemen.

In het bestuur van de Rust Foundation zitten elf leden. Die komen deels van grote techbedrijven zoals Google, Amazon, Huawei en Microsoft. De bestuursleden hebben dinsdag hun eerste vergadering. Daarmee is de Rust Foundation officieel een feit, nadat die vorig jaar zomer werd aangekondigd.

De originele maker van Rust is Mozilla. Dat heeft alle infrastructuur rondom het project overgedragen aan de nieuwe stichting. Daar valt ook de crates.io-registry onder.

Met een aparte stichting moet duidelijker worden vastgelegd dat Rust een onafhankelijk project is. De stichting gaat zichzelf dan ook niet zozeer bezig houden met ontwikkelingen in de programmeertaal zelf; dat laat het aan voornamelijk het core team over.

De stichting beheert een jaarlijks budget van een miljoen dollar. Daarmee wordt onder andere promotie gedaan via evenementen, en worden er nieuwe diensten rondom de programmeertaal geïntroduceerd.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (114)

Ik ben een ervaren programmeur, voornamelijk C en een beetje C++ en Java en uit interesse heb ik wel eens naar Rust gekeken, maar ik vind het er toch niet vriendelijk uitzien om te programmeren, zeker niet in vergelijking met bijv. .Net. Zijn er Tweakers hier die ervaring hebben met Rust en mij kunnen overtuigen van m'n ongelijk of het juist met me eens zijn?

Zoals Steve Klabnik het me jaren geleden uitlegde: De meest voorkomende fouten / exploits in C en C++ applicaties komen door geheugen issues / bufferoverflows. Rust regelt dit voor je en garandeert op die manier geheugen veiligheid, zonder een garbage collector zoals Java en Erlang dat doen. Hierdoor heb je dus wel de snelheid, zonder de gevaren van mogelijke exploits. Om deze reden wordt heel veel Linux tooling nu herschreven naar Rust. Even snel, maar veiliger en robuster.

[Reactie gewijzigd door BCC op 9 februari 2021 10:47]

Binnen rust code zitten prima!

Maar hoe zit het dan met het feit dat je ook naar systeem functies kan gaan (unsafe in rust)
Is er al ervaring mee of rust zelf dan veilig blijft?

In dat geval worden de normale controles niet meer gedaan en zit je op hetzelfde "veiligheidsniveau" als bijvoorbeeld C++. Dus als je unsafe moet gebruiken (wat in 99.9% van de gevallen niet nodig is) is het belangrijk dat je deze code, zelf, heel goed controlleerd. Wat het fijne hiervan is, is dat als je een codebase opent en ziet dat er geen unsafe wordt gebruikt, je vrij zeker bent dat er geen rare bugs achter de schermen zullen ontstaan.

Niet geheel waar. Het is een beetje een mythe dat de borrow checker niks meer doet in unsafe. Je kunt eigenlijk maar 5 extra dingen doen in unsafe:

• Dereference a raw pointer
• Call an unsafe function or method
• Access or modify a mutable static variable
• Implement an unsafe trait
• Access fields of unions

Door het kunnen dereferencen van pointers zou je wel dingen van de borrow checker verborgen kunnen houden. Als je de borrow checker regels wil overtreden, dat mag niet, want dat is Undefined Behaviour.

Maar de fouten die je maakt in unsafe code kunnen escaleren naar safe code. Zaken als double-free, use-after-free en buffer overflow komen ook in Rust voor, juist door unsafe stukken code:

https://arxiv.org/pdf/2003.03296.pdf

De borrow checker is dus een hulpmiddel, maar geen garantie. Denk dat veel ontwikkelaars zich nog niet goed realiseren wat de consequenties zijn van unsafe code.

"Play stupid games, win stupid prizes" Tja, soms moet je unsafe calls doen en dan ben je zelf verantwoordelijk voor de goede afhandeling.

Het is niet even snel als C, laten we dat gelijk maar afstrepen.

Er zit ook een wezenlijk verschil tussen een garbage collector zoals Java (OOP) of Erlang (functional) gebruikt, maar überhaupt is een garbage collector niet speciaal een onderdeel van de taal, maar vaak een implementatie, zoals bijvoorbeeld .Net doet voor C(++) of browsers hun eigen garbage collector voor JS.

Geheugen issues/ buffer overflows komen dan ook door de programmeur en niet door de taal zelf.

Rust schijnt gemiddeld gezien over een set van benchmarks tegenwoordig sneller te zijn dan C:

https://benchmarksgame-te...programs-are-fastest.html

En geheugenissues etc komen inderdaad door de programmeur, en dat is juist het hele idee achter Rust. Veel hele ervaren C++ en C developers zeggen ook dat hoe goed je ook bent dat het vrijweloonmogelijk is om helemaal te voorkomen in een applicatie op een redelijke schaal.

Echter zijn de compilers van talen zoals Rust weer geschreven in C(++).

Dus het hangt van een baklading C(++) code af hoe goed Rust code wordt gecompiled naar binaire code of het daadwerkelijk sneller is dan idiomatische C(++) code.

Dus dan is het nog steeds de vraag of je daadwerkelijk kan stellen dat Rust sneller is dan C. Misschien in een idiomatische context voor de developer, maar ik vind dat niet genoeg om zo hard die conclusie te trekken.

Zoals ik hierboven stelde is veel Rust code sneller vanwege het (ge)makkelijker gebruik kunnen maken van de juiste data structure en of algoritme for the job. Betekent dat alle rust altijd sneller is? Nee. Is het makkelijker om snellere code te schrijven in rust: Anekdotisch bewijs zegt tot nu toe ja.

Je moet niet vergeten hoeveel werk de compiler onderwater doet aan optimilasities, veel programmers denken soms dat ze "Snelle" code schrijven zonder hier daadwerkelijke bewijs voor te hebben. Het blijkt ook dat menig "truukje" vaak al door de compiler opgepakt of gesnapt wordt en optimized. Interessante talk van de maker van godbolt hierover: https://www.youtube.com/watch?v=w0sz5WbS5AM

Hoe verder de codegen werkt, is niet belangrijk. Rust maakt gebruik van LLVM, zoals C en C++ dat ook (kunnen) doen. Het enige wat je nodig hebt is een frontend die je code omzvet naar LLVM-IR, een soort bytecode die door LLVM gebruikt wordt om optimilasities uit te voeren en uiteindelijk een binary te produceren voor de target die je selecteert (zoals aarch64, x86 etc.)

Ik snap niet helemaal wat je bedoelt. Heb je het dan over de compile tijden of executie tijden (performance) van de binary code die eruit komt rollen?

De Rust compiler is gemaakt op basis van LLVM en kan goed zijn dat dit C++ of C is. Maar LLVM kan neem ik aan ook geport worden naar Rust, maar dat zal voor de binary die het produceert niets uitmaken. Als de werking (logica) van de code gelijk blijft dan is de output identiek. Maakt het dan uit voor de snelheid/performance van de binary of LLVM in C++ of Rust is geschreven?

Mijn punt was meer dat een claim dat een taal sneller is, erg lastig is in deze situaties.

Met zulke lage level talen is het niet alleen aan de hand van de programmeur hoe goed het is geoptimaliseerd, maar ook hoe de compiler zijn werk doet. Het is dan afhankelijk van hoe goed de C++ code de Rust code omzet.

LLVM en daarbij ook Clang is geschreven in C++ en dat zal ook niet veranderen. Niet om Rust, maar vanwege praktischere redenen.

Geheugen issues/ buffer overflows komen dan ook door de programmeur en niet door de taal zelf.

Dat is precies de mentaliteit waardoor we inmiddels 25 jaar en wereldwijd minstens 250 miljard dollar aan schade en ellende verder zijn, terwijl vermijdbare software bugs nog steeds aan de orde van de dag zijn.

Het argument dat het aan de programmeurs ligt (lees: dat de programmeurs moeten veranderen, en niet de taal) is inmiddels door de praktijk weerlegd. Want programmeurs worden blijkbaar niet vanzelf beter. En dus moeten ze met betere tools tegen zichzelf beschermen.

Hier maak je zeker een valide punt.

Echter bestaat het beroep ook nog niet zo lang, de mensen die er vanaf jongs af aan mee bezig zijn stromen pas recentelijk het werk veld in.
Persoonlijk denk ik dan ook dat dat de gemiddelde kwaliteit omhoog gaat per generatie.

Hoho, dat is veel te kort door de bocht. In C kan ik makkelijk code schrijven die langzamer is dan in rust.
Punt is dat volledig geoptimaliseerde code in C misschien sneller is dan Rust, maar in Rust its het een stuk gemakkelijker om "goede" code te schrijven.
(Zelfde geldt trouwens voor C++).
Ook is het een heel stuk moeilijker om code te schrijven dat memory leaked en zo.

Rustc is verdeeld in meerdere lagen. Alle behalve de backend zijn in Rust geschreven. De backend is nu LLVM dat in C++ is geschreven.
Het is een erg groot voordeel om LLVM te gebruiken omdat het simpelweg erg goed is in wat het doet en omdat de backend door meerdere compilers wordt gebruikt, zijn er veel mensen die er aan contributen.

Een probleem van LLVM is weer dat die erg langzaam is. Al die optimalisaties doen is niet gratis, dus er wordt gewerkt aan de Cranelift backend die volgens mij wel helemaal in Rust is geschreven. Deze backend is meer gespitst op compilatie snelheid en minder runtime performance. LLVM zal dus nog niet weg gaan.

Clangd en Clang-Tidy zijn in mijn ervaring het gene wat de meeste resources kost van het hele LLVM pakket. Het evalueren van het gebruik van grote libraries zoals BOOST is dan ook erg zwaar.

Handgeschreven assembly wint het altijd van gecompileerde code, maar het schaalt niet. Met voldoende middelen kan je C en C++ veilig programmeren, maar het schaalt niet.

Voor veel toepassingen geldt zelfs dat een te lage programmeertaal uitnodigt tot optimaliseren zonder profilen. Ik heb de afgelopen 30 jaar meermalen code in assembly, C en FORTRAN vervangen door Perl scripts, die minder CPU nodig hadden dan de hand geoptimaliseerde code die het verving. Simpelweg omdat de optimalisatie op een te laag niveau zat. En dan denk je, met de kennis die ik hiermee heb opgedaan schrijf ik het even overnieuw in C. Zo ben ik er achter gekomen dat ook ik niet immuun ben voor het second system effect :-)

Ik begin tegenwoordig in Python, Ruby of Perl, en ga pas lager als daar aanleiding voor is. En die aanleiding is dan profiling, niet een gut feeling.

Absoluut.

Het is ook veel efficiënter (kosten en tijd) om überhaupt eerst een MVP te maken in een higher level language en daarna te evalueren of het beter is om het te herschrijven.
In mijn ervaring binnen het werkveld is dit ook wel gebruikelijk.

Zoals Steve Klabnik het me jaren geleden uitlegde: De meest voorkomende fouten / exploits in C en C++ applicaties komen door geheugen issues / bufferoverflows.

Als je jaren-negentig C++ schrijft klopt dat wel. Als je gewoon modern C++ schrijft en weet wat je doet komt het eigenlijk niet voor. Afgelopen decenium van dagelijks C++ programmeren, miljoenen regels, heb ik veel bugs de revue zien passeren, maar nog nooit een geheugen issues of buffer overflow in mijn code.

Mensen die een taal als excuus gebruiken om geen fouten te kunnen maken [sic] is voor mij echt een enorme rode vlag.

[Reactie gewijzigd door Zoijar op 9 februari 2021 15:39]

Zoals je al zegt, je kunt ook in C++ goede code schrijven. Maar in C++ is het veel gemakkelijker dan in bijvoorbeeld Rust om slechte code te schrijven. Doordat er gigantisch veel pitfalls zijn in C++, zullen alleen programmeurs met heel veel specifieke C++ ervaring deze weten die te omzeilen.

Zeker is het makkelijker om in C++ slechte code te schrijven. Zo heb je bijvoorbeeld het "copy constructor" probleem. Waarbij het probleem de afwijkende implementatie is per systeem. Verder het string drama, waarbij C++ gewoon ontzettend moeilijk met UTF-8 overweg kan.

Ik denk dat Dann74 niet twijfelt aan de kwaliteit/performance, maar meer struikelt over een andere syntax die er voor hem wellicht raar/rommelig/whatever uit ziet. Dat kan, het zal ook deels gewenning zijn.

Aanvullend hierop worden er ook experimenten gedaan om drivers voor linux in rust te ontwikkelen nav Linus zijn voorzichtige opmerking over dat rust potentieel interessant "kan" zijn. Samen met de aankomende clang build optimalisaties zijn dit de eerste experimentele stappen.

In Rust kan je vaak snellere code schrijven dan in C, simpelweg omdat sommige algoritmes/data structuren makkelijker / realistischer in een grote codebase te gebruiken zijn.

Daarnaast is het niet het meest vriendelijke ding om mee te beginnen nee, het is toch even wennen aan een compiler die wat meer zeurt. De officiele docs voor starten zijn wel erg goed verder: https://doc.rust-lang.org/stable/book/

Wat ook leuk is aan Rust is dat cross compilen toch wat makkelijker is dan met veel andere talen, omdat je de toolchains gewoon kan managen met rustup en veel targets al beschikbaar zijn zonder werk aan jouw kant

De kracht van Rust zit het typesysteem en de checks die hierdoor mogelijk worden. Ja, memory-safety bugs heb je niet in Java, maar kan Java race conditions en null derefs vinden bij het compileren?

Ik heb een tijdje terug een paar artikelen geschreven over wat Rust allemaal kan verhelpen nog voordat je programma gestart is voor als je wat meer details en voorbeelden wil zien:

* "How Rust Helps You Prevent Bugs" -> https://polyfloyd.net/post/how-rust-helps-you-prevent-bugs/
* "Compile Time Prevention of SQL-Injections in Rust" -> https://polyfloyd.net/pos...ention-of-sql-injections/

Ik zie een heleboel reacties hierop die de functionaliteit van de taal verdedigen en maar weinig over waar OP half naar doelt, de syntax. Rare operators als =>, | | en jawel, het ' teken voor lifetime. Je zal er vast aan kunnen wennen maar ik vraag mij toch af of dit wel de juiste richting is voor de toekomst van programmeertalen. Zelf had ik graag een vriendelijkere versie van C gezien met memory safety, wat C++ had moeten zijn. Helaas is het dat niet door het gedateerde compilatie model, matige metaprogramming in de vorm van templates en te veel nieuwe features die in de standard library worden gepropt. Geproduceerde software blijft evolueren, maar talen blijven achter imo.

Dit.. Precies dit.
Totaal mee eens @niico0708 want door de syntax wordt het moeilijker en onoverzichtelijker.
Als ze het nu zo hadden gemaakt, dat het de gebruikelijke syntax niet aantast, zou ik me er makkelijk in kunnen verdiepen.

eens naar Rust gekeken, maar ik vind het er toch niet vriendelijk uitzien om te programmeren, zeker niet in vergelijking met bijv. .Net.

Ik hobby wel eens met Rust en ben het helaas met je eens. Ik zou graag zeggen dat Rust de performance van C/C++ combineert met de hogere abstractie van C#/Java(Script), maar ik zou liegen als ik beweer dat dat zonder prijs gekomen is. Als ik bekijk hoe bepaalde code in JavaScript er uit ziet en wat het alternatief in Rust is dan schrik je; er is zoveel meer om rekening mee te houden. Als je een variabele wilt delen tussen twee threads dan moet die variabele aan allerlei eisen voldoen. In JavaScript/C# zijn dat soort eisen meer aan toeval overgelaten; hoe groot is nou echt de kans dat twee processen tegelijkertijd precies dezelfde variabele willen veranderen en wat is nou echt de schade als het gebeurt? Programmeren in Rust voelt daardoor aan als een vrij theoretische/academische exercitie; pas als je kan garanderen dat er tijdens het uitvoeren niets mis kan gaan is de compiler tevreden, en soms is de compiler daarin onnodig voorzichtig. Ik maak mezelf wijs dat die extra moeite die je er in steekt om aan alle (al dan niet theoretische) eisen te voldoen het waard zijn omdat je achteraf niet of nauwelijks met onverwacht gedrag geconfronteerd wordt; ik heb niet genoeg praktijkervaring om te weten of dat echt waar is.

Ik denk dat Rust hierdoor een vrij steile leercurve heeft. Maar ik moet zeggen, ik geniet er wel van. Je bent namelijk problemen aan het oplossen voordat ze bestaan en in zekere zin is dat de droom van een ingenieur; een ontwerp zo robuust maken dat er niets mis kan gaan.

[Reactie gewijzigd door 84hannes op 9 februari 2021 11:15]

hoe groot is nou echt de kans dat twee processen tegelijkertijd precies dezelfde variabele willen veranderen en wat is nou echt de schade als het gebeurt?

TL;DR: kans is 100%, schade groot

Dit is een van de grote problemen als je multi-threaded software schrijft: uitwisselen informatie tussen de threads. Voor een single threaded applicatie zal het niet zo'n issue zijn. Toen CPUs nog single core waren kwam je er vaak wel mee weg, omdat effectief de processen niet precies tegelijkertijd konden lopen. Maar met introductie van hyperthreading en multi-core CPUs is dat niet meer het geval. Toen best wel wat software gezien die alleen nog werkte als je die keihard op 1 fixed CPU core vastzette.

Heb zelf geen ervaring met Rust, maar wel met Java en wat andere programmeer talen voor grootschalige parallelle verwerking van hoge aantallen aanroepen. Ik geef je 100% garantie dat het fout gaat als je geen goede toegang tot shared resources zoals een gezamenlijke variabele tussen processen regelt.

Wat is de schade? Ligt er maar net aan waar de software voor gebruikt wordt. Ik heb aan databases en telecom netwerken gewerkt: gewoon niet acceptabel. Dit zijn de programmeer fouten die met gemak hele systemen onderuit halen. Of games die er spontaan uitklappen, idiote dingen laten zien of vastlopen. Het is erg fijn als de programmeer taal / compiler je behoedt voor het maken van dit soort fouten. Dit zijn in mijn ervaring namelijk heel erg vervelende fouten om te achterhalen.

Als ik me voorstel hoe een bestaand stuk C++-code in Rust geprogrammeerd zou worden dan komt dat vaak op veel meer regels code neer en veel meer problemen die vooraf opgelost moeten worden. Als ik dan nadenk over de reden waarom dit moet gebeuren is dat er veel corner-cases zijn die in C++ niet afgedekt zijn. En toch draait de code al jaren. Niet probleemloos, maar in de praktijk komt niet ieder theoretisch probleem ook echt voor. De compiler weet dat echter niet. Ik zeg niet dat dat erg is, want ik heb liever een compiler die te voorzichtig is dan te onvoorzichtig.

You're smarter than Rust

Bron: https://fasterthanli.me/a...ated-its-not-you-its-rust

Leuk detail, een jaar of 10 terug draaide de kaartjesautomaten van de NS op een single thread, maar de voor het testen draaide de emulator op een multi-core PC - dit gaf gekke foutmeldingen, totdat er een tooltje gevonden werd, dat de applicatie op 1 core dwong. Emulatieproblemen opgelost, en extra kennis opgedaan waar op gelet moet worden bij een volgende hardware upgrade.

Multi-threaded vraagt gewoon om een andere aanpak, je kan niet zomaar je single-threaded code en data structuren overzetten. Maar in al mijn ervaring hiermee zijn de nieuwere talen c# etc.. wel een stuk eenvoudiger dan c, c++.

En inderdaad je kunt rare dingen meemaken, heb zelf ook drivers gemaakt die multi-threaded aangeroepen worden en dan kom je vanzelf in die problemen.

Lastige is natuurlijk als je al een legacy systeem hebt en je moet daarmee omgaan dan ga je maar een que maken en die stuk voor stuk laten verwerken.

JavaScript is meer asynchroon dan parallel - onder de kap worden dingen over het algemeen geserialiseerd naar een reeks microtaken. Hoewel het mogelijk is om dingen op een andere thread uit te voeren kan je niet zomaar state delen tussen verschillende threads zoals in C/C++ (met alle gevaren daarvan). Rust maakt het wat dat betreft juist een stuk makkelijker om daadwerkelijk dezelfde data te delen tussen meerdere threads.

[Reactie gewijzigd door Mitsuko op 9 februari 2021 12:06]

Rust maakt het wat dat betreft juist een stuk makkelijker om daadwerkelijk dezelfde data te delen tussen meerdere threads.

Meer precies: Rust maakt het makkelijker om deze data veilig te delen.

Ja inderdaad, je hoeft in C++ niks extra's te doen en met een beetje geluk zorgt het niet voor problemen op x86 en verwante architecturen omdat ze een "sterk" geheugenmodel hebben, maar met architecturen als ARM heb je grote kans dat het helemaal mis gaat.

[Reactie gewijzigd door Mitsuko op 9 februari 2021 13:28]

Async in Rust heeft voor zover ik hoor nog wel wat werk. Is ook nog allemaal vrij "nieuw" ( https://areweasyncyet.rs ). Maar kom er is nog wel heel veel nieuw in Rust, omdat het zelf nog een nieuwe taal is.

[...]
Programmeren in Rust voelt daardoor aan als een vrij theoretische/academische exercitie; pas als je kan garanderen dat er tijdens het uitvoeren niets mis kan gaan is de compiler tevreden, en soms is de compiler daarin onnodig voorzichtig.
...
Ik denk dat Rust hierdoor een vrij steile leercurve heeft. Maar ik moet zeggen, ik geniet er wel van. Je bent namelijk problemen aan het oplossen voordat ze bestaan en in zekere zin is dat de droom van een ingenieur; een ontwerp zo robuust maken dat er niets mis kan gaan.

Dat Rust nogal academisch aanvoelt vind ik ook wel. Beetje een taal van en voor computerwetenschappers.

Dat je in Rust heel expliciet moet zijn, zorgt buiten latere onverwacht gedrag vermijden, er ook voor dat de compiler/LLVM, heel veel optimalisaties kan doen. Met bijgevolg zeer snel draaiende applicaties.

Dat je in Rust heel expliciet moet zijn, zorgt buiten latere onverwacht gedrag vermijden, er ook voor dat de compiler/LLVM, heel veel optimalisaties kan doen. Met bijgevolg zeer snel draaiende applicaties.

Daar komt bij dat de Rust compiler beter wordt. Vroeger moest je bijvoorbeeld heel veel naamloze scopes ({...}) toevoegen, maar sinds de introductie van Non-lexical lifetimes hoef je de compiler niet meer expliciet te vertellen dat je een variabele nooit meer gaat gebruiken; dat kan de compiler zelf zien. Als je hem vervolgens toch gaat gebruiken corrigeert de compiler je op een heel leesbare manier. E.g. vroeger schreef ik

fn main() {
____let mut x = 5; {
________let y = &x;
____}
____let z = &mut x;
}

maar tegenwoordig werkt

fn main() {
____let mut x = 5;
____let y = &x;
____let z = &mut x;
}

gewoon.

[Reactie gewijzigd door 84hannes op 9 februari 2021 13:40]

Als "ervaren programmeur" zou je toch ook wel door moeten hebben dat C en C++ vergelijken met .NET een zeer vreemde vergelijking is. C, C++ en Rust zijn gecompileerde talen, en draaien dus volledig als binaries.

.NET framework, Java, en veel andere high-level talen die "vriendelijker om te programmeren" zijn hebben een runtime/interpreter nodig, omdat ze naar een intermediate language gecompileerd zijn die niet rechtstreeks uitgevoerd kan worden. Dat is bij Rust niet het geval.

Met GraalVM kan je Java ook compileren naar native images hoor. Dat een taal een VM/interpreter nodig heeft niet per se iets met de taal te maken, als met de opvattingen van degene die hem uitgevoerd wil hebben.

Alleen ondersteunt GraalVM dan ook niet alles wat Java te bieden heeft. Probeer maar eens een applicatie die met JSON moet omgaan (wat vaak reflection nodig heeft in Java) te draaien met GraalVM. Taal en framework/runtime staan in theorie los van elkaar, maar in praktijk dan weer net iets minder.

Hoe programmeervriendelijk een taal is hangt niet af van compileren of interpreten.

Op details wijken Java en C++ af, maar verder lijkt de syntax bijna hetzelfde.

Ook Java-code kan best gecompileerd worden.

Een groot voordeel van Java t.o.v. C is dat in Java ongebruikte objecten (die geen referentie hebben naar andere objecten) periodiek uit het geheugen opgeruimd worden (zogenaamde garbage collection), waar ze in C blijven bestaan (tenzij je ze zelf opruimt) waardoor het geheugen op den duur vol kan lopen en de applicatie stopt.

Vroeger had je voor Basic ook interpreters en compilers.

Ten eerste is Garbage Collection niet per definitie een voordeel, tenzij je op gebied van programmeervriendelijkheid doelde. Bovendien heb je in C++ ook Smart Pointers, die voor een vergelijkbare situatie kunnen zorgen, mocht dat écht nodig zijn.

[Reactie gewijzigd door jetspiking op 9 februari 2021 13:45]

Vanuit programmeur opzicht maakt het toch niks uit of je een interpreter hebt of niet? Je ontwikkelt een applicatie, die moet draaien op de hardware, daar kan een interpreter tussen zitten ja, maar dat heeft verder niets te maken met of een taal makkelijk te programmeren is. Vanuit taal point of view kan je iedere taal/syntax met elkaar vergelijken, interpreter of niet

Ihmo zelfs zo "vriendelijk" dat het heel gemakkelijk is om slechte code te schrijven. Ik zie op stack overflow soms de meest verschrikkelijke productie .net code langskomen...

Slechte code schrijven kan in elke taal. Dat ligt niet aan de taal, maar aan de programmeur.

De code paste meuk op SO is dan ook vaak van het niveau "can I has the code please".

Ik werk nu sinds ongeveer twee maanden aan een open source project met Rust (Airbus A320 voor Microsoft Flight Sim nabouwen). Ik vind het een mooie taal en gebruik het met veel plezier. Het is mijn eerste "low-level" taal. Komende vanuit een C# en JavaScript achtergrond is het een veiligere stap dan bijv. C++. Er zit interessante meta-programming (macros) in die ik nog verder moet onderzoeken.

Voor mijn gevoel gaat C# de laatste jaren achteruit. Het is een mengelmoes van concepten aan het worden. Eigenlijk zou men die taal als "afgerond" moeten beschouwen, maar om het relevant te laten voelen brengt men nog altijd nieuwe language features uit. Wat dat betreft vind ik Rust ook een verademing: gewoon degelijk over nagedacht zoals dat met eerdere C# versies ook was, namelijk: zonder gekke fratsen die ik weleenswaar kan snappen maar het voor de gemiddelde programmeur echt niet makkelijker maken.

[Reactie gewijzigd door DutchCommando op 9 februari 2021 12:23]

interessant, het uitbrengen van nieuwe features is slecht? moet zelf zeggen dat ik c# echt verdomd goed in elkaar vind zitten.

Voor een deel, maar d'r zitten ook hele rare (lees: slechte) zaken in. Zoals default interface implementaties waarbij je properties of methodes van een interface als default implementaties kunt geven..

Daarnaast weet ik ook nog niet zeker of ik de 'nieuwe' library structuur prettig vind waarbij alle libaries via nuget komen ipv het framework zelf. Het grootste voordeel is natuurlijk dat deze packages buiten de reguliere .NET framework releases updates kunnen krijgen. Helaas is de documentatie van Microsoft wel flink achteruit gegaan. De meeste packages verwijzen naar een algemene page ipv referentie documentatie..

Aan de andere kant is C# nog steeds mijn defacto programmeertaal omdat ik het al ruim 20 jaar gebruik.

C# is mooi voor GUI tools te maken.
Als web service e.d., nee, dan ga ik liever over op GO of RUST (als ik er ooit weer reden zie om het te leren). C# heeft teveel implicaties, zoals het niet kunnen aanpassen bijvoorbeeld van de "server" header van een API web service, en moet je allerlij customizations en/of NGINX oid tussen hangen, wil je uberhaupt die header kunnen aanpassen. Teveel proprietary.

Het aanpassen van een header is letterlijk 1 regel code in C#.
Dus waar heb je het over?

[Reactie gewijzigd door Proliges op 9 februari 2021 14:43]

Probeer jij de "server" header string aan te passen.
Ik wacht op antwoord, want op heden heeft zelfs een "Ervaren" C# programmeur in mijn vriendenkring hier ook geen oplossing op. Dit omdat MS het hard-coded in hun HTTP server library vast heeft gezet, en je dit niet kan aanpassen.

[Reactie gewijzigd door Power2All op 9 februari 2021 15:36]

De server header kun je toch gewoon aanpassen door een andere server te kiezen? Wat is het praktisch nut om deze aan te passen?

Andere server ?
Vertel, nu ben ik geinteresseerd, want tot nu toe heb ik nog geen optie kunnen vinden van een API HTTP server (C# lib) waar je de server header (dus de header die zichzelf identificeerd zoals Apache, NGINX, etc..) van kan aanpassen, of zelfs weg kan halen.

Andere server ?
Vertel, nu ben ik geinteresseerd, want tot nu toe heb ik nog geen optie kunnen vinden van een API HTTP server (C# lib) waar je de server header (dus de header die zichzelf identificeerd zoals Apache, NGINX, etc..) van kan aanpassen, of zelfs weg kan halen.

Uit interesse. Wat bedoel je exact met de server header? Bedoel je die regels als x-powered-by?

Volgens mij kun je die namelijk vervangen of verwijderen (niet zeker of het met allemaal kan).

Hangt misschien ook wel van je type project af.

Misschien begrijp ik je niet goed. Maar we hebben het over de server header waar de web server version zoals IIS of Apache weergegeven wordt toch?

Klopt.
Ik ben bezig met een API te maken, en wil dit graag kunnen aanpassen (om wat voor reden dan ook). Het is een beetje apart dat alleen MS zijn eigen libraries locked dat je deze niet kan aanpassen. Alle andere headers kun je gewoon aanpassen naar je eigen behoefte, behalve de, en dat is toch zeer opmerkelijk.
Oop dit moment gebruik ik GO, en kan je dat allemaal doen met de ingebouwde HTTP tools, PHP kan dat ook, NGINX kun je ook wijzigen, hetzelfde geldt ook voor Apache, etc... maar niet in C#... Da's vreemd.

[Reactie gewijzigd door Power2All op 10 februari 2021 10:39]

Maar waarom zou je het aan willen passen? Het geeft gewoon een indicatie van webserver waar je mee verbonden bent. Als je een andere webserver kiest past deze aan. Als je de indicatie niet weer wil geven dan haal je hem weg.

Maar ik kan geen enkele use case bedenken waarom je dat aan zou willen passen naar iets anders.

Ik wil gewoon niet dat mensen kunnen zien waar mijn app op draait.
Hetzelfde geldt dat sommigen niet willen dat mensen weten dat ze met Apache of NGINX draaien, laat staan welke versie.
Het moet niet uitmaken of het een use-case heeft of niet, deze header locking is gewoon sneu.
Daarnaast een benchmark gedaan met HTTP/1.1 (en 1.0, maar 1.0 is sowieso altijd traag), en C# heeft moeite met veel concurrent connecties, waar GO en RUST geen moeite hebben, dus dat was de 2de reden dat ik niet met C# verder ging.

[Reactie gewijzigd door Power2All op 10 februari 2021 11:53]

Maar je kan de header gewoon simpelweg niet tonen.
Gewoon in je config file, of gewoon in de code, een regeltje inkloppen en je ziet het niet meer.

Again, paste dat regeltje hier wat dat is, want ik heb al van alles geprobeerd om het te manipuleren of aan te passen. Simpel weg halen, of wijzigen (de method ervoor) werkt namelijk niet.

<security>
<requestFiltering removeServerHeader="true" />
</security>

of

<customHeaders>
<remove name="X-Powered-By" />
</customHeaders>

of de outbound rules rewriten maar dat is een paar regels meer.

[Reactie gewijzigd door Proliges op 11 februari 2021 10:27]

Uhh volgens mij ga je de verkeerde kant op.
Dit is een pure C# command line app, de fix die jij aanbiedt is voor IIS servers.
https://docs.microsoft.co...httplistener?view=net-5.0
Dit is wat ik gebruik voor de HTTP server, geen idee waar IIS hierbij geplaatst moet worden, zover ik weet is IIS gewoon een web server zoals Apache en NGINX, maar ik heb het puur over een app die zijn eigen web service draait.

Waar plaats je die app dan? Die draait toch niet op localhost neem ik aan? Volgens mij is het vrij normaal om dat op een webserver te plaatsen.

[Reactie gewijzigd door Proliges op 11 februari 2021 23:10]

Uhhh nee ?
Je gaat een API niet hosten op een web server, die is niet geschikt om 8000 connecties per seconden te behandelen. Het is geen simpele website, want je begrijpt blijkbaar niet helemaal dat dit een custom web service app is...

Ik ken jou situatie niet, dat klopt. Ik weet wel dat onze applicaties draaien op IIS en dat sommige van onze APIs op bepaalde momenten (ruim) over de 25000 connecties per seconden gaan.

Dus ik weet niet tegen wat voor problemen jij aanloopt, maar wij kennen ze in ieder geval niet.

Zijn die afkomstig van kleine IP ranges, of 25000 connecties concurrency per seconden van verschillende IP locaties/landen ?
Ben zeer benieuwd, want NGINX/Apache gaat dan toch echt moeite krijgen, voor de OS, aangezien die alle connecties er doorheen moet persen, nevermind dat de overhead/timeout ook meespeeld.
Host je dit op 1 OS/VM of maak je gebruik van load balancing ?

[Reactie gewijzigd door Power2All op 12 februari 2021 11:35]

Dat is gewoon gewenning, ik weet nog dat ik eerst naar F# code zat te kijken omdat ik 'wel even een bug zou fixen daar' en dat mijn hoofd ontplofte. Gewoon doorzetten, zo keek je ooit ook naar C++

Rust is ook niet zozeer ontworpen om "vriendelijk" te zijn. Het is een taal die je dwingt om goed na te denken over de structuur van je code, verantwoordelijkheden goed te verdelen, en eigendom van data duidelijk te definiëren. Het is even doorbijten om de juiste mindset te vinden, maar zodra het klikt levert het je code op die vele malen robuuster en veiliger is dan wat je van de meeste programmertalen krijgt. Overigens vind ik het uit ervaring niet per sé een moeilijkere taal om te leren dan C of C++; het is alleen op bepaalde vlakken wat anders, dus zul je je gewoontes er op moeten aanpassen.

Ik heb het geprobeerd.
Zit in het eco-systeem van PHP, Python, GoLang en JavaScript.
Heb geprobeerd om een tool te maken in RUST wat ik perfect in GO heb gekregen, maar er zitten teveel haken en ogen aan RUST, de leer curve is gewoon, te hoog.
Snapte er de ballen van waarom er een bepaalde syntax gebruikt werdt, wat alleen maar verwarrender werd naarmaten ik ernaar keek, echt niet goed voor beginners ook.
Blijf door dit, toch maar bij Go, waar ik meer en meer ervaren in begin te worden, en de snelheid kwa threading bijna dezelfde, als nog beter heb, dan bij RUST, dus de behoefte is er niet meer. Het probleem waar ik veelvuldig tegenaan liep, was de lange iteration tijd, maar dat heb ik verholpen door zelf een "chunk" systeem te maken, die non-blocking is. Datzelfde had ik ook bij RUST moeten toepassen, als ik non-blocking wil gaan programmeren.

[Reactie gewijzigd door Power2All op 9 februari 2021 13:34]

Het ziet er redelijk javascript/typescript-like uit dus ja dat is even wennen als je C-talen gewend bent. Vandaag de dag is het niet slecht voor je CV om bekend te zijn met de javascript familie van talen, Rust lijkt me dan wel een zeer geschikte kandidaat om in te stappen als je C gewend bent.

alleen jammer dat er nog geen fatsoenlijk IDE is zoals bijv Goland er is voor Go

VSCode met Rust Analyer werkt super!
En IntelliJ met de Rust plugin werkt ook erg goed.

Verder is de project setup erg simpel. Eigenlijk is het maar 1 toml file, dus dat is prima zelf bij te houden.

Wat is er mis met vscode implementatie?

VSCode is een heel geavanceerde teksteditor. Daar vroeg @PainkillA echter niet naar. Nu is de scheidslijn natuurlijk een beetje lastig, maar naar mijn ervaring beheer je bij VSCode niet echt een Rust project, maar meer een map met Rust bestanden. Ik zal IntelliJ, zoals opgemerkt door @Cyb weer eens een kans gaan geven; IntelliJ is immers wel een IDE.

[Reactie gewijzigd door 84hannes op 9 februari 2021 15:26]

Je kan VSCode naar mijn idee geavanceerder en meer compleet maken dan de meeste IDE's. Daarnaast is het ook nog een stuk overzichtelijker, aangezien alle extra functies een duidelijke modulaire vorm hebben, waardoor het duidelijk is waar je elke functie moet zoeken. Iets wat ik over weinig IDE's kan zeggen.

[Reactie gewijzigd door pofsok op 9 februari 2021 15:24]

Daarnaast is het ook nog een stuk overzichtelijker, aangezien alle extra functies een duidelijke modulaire vorm hebben,

offtopic:
Kun je hier over uitweiden? Ik benader commando's altijd via F1, maar hoe meer extensies ik installeer, hoe onoverzichtelijker het wordt. Als ik jou goed interpreteer gebruik ik VSCode verkeerd.

Bij alle extensies (die ik gebruik in ieder geval) komt er of een extra label met uitklapbare window in je linker sidebar of komt er een extra icoontje aan de linkerkant te staan, waar alle belangrijke nieuwe functionaliteiten van de extensie zijn te vinden. Daarnaast installeer je dus alle functionaliteiten zelf, en heb je een direct overzicht/kennis van wat er met je "IDE" mogelijk is. Dat is wat ik bedoel met modulair.

Bij IDE's die ik heb gebruikt, voelde het soms nogal willekeurig welke ondersteuning er van te voren in zitten, en voor welke je extensies moet installeren. En soms zitten er ook functionaliteiten in die ik helemaal niet gebruik, maar die wel altijd in mijn context menu blijven staan.

Ik heb vooral met wat "oudere" IDE's gewerkt, zoals Eclipse of CodeBlocks. En VSCode is voor mij echt een verademing. Ik heb alle flexibiliteit die ik mij kan wensen. Daarnaast vind ik het ook heel fijn dat voor alle verschillende talen dezelfde editor kan gebruiken, al zou ik het wel fijn vinden als bepaalde extensie automatisch uitgeschakeld worden als je een bepaalde taal gebruikt worden (op dit moment kan je wel extensies per workspace aan/uitschakelen, maar is niet helemaal ideaal) zodat ook de zoek functie iets overzichtelijker blijft.

Dat het voor mij trouwens goed werkt of fijn is, betekent trouwens niet dat dit voor iedereen fijn is. Maar ik vind mijn workflow heel fijn in VSCode.

lijkt me een gat in de markt als je dit straks kunt programmeren als een van de eerste.

Zelfde comment als de rest, maar dan met een wiki pagina

https://en.wikipedia.org/wiki/Rust_(programming_language)

vanaf 2006 al dus.

Bijna oud genoeg om te drinken.

Haha

kost wat, heb je ook wat!

De taal (en bijbehorende tooling) is al meer dan 10 jaar uit, dus laat dat gat in de markt maar zitten.

Er wordt al het één en ander in rust geschreven. Zo is er bitwarden_rs, een alternatieve back-end voor Bitwarden die volledig vrij is in gebruik.

Dat is slechts een enkel voorbeeld. Er zijn er veel meer.

[Reactie gewijzigd door The Zep Man op 9 februari 2021 10:26]

Nou ja, 10 jaar...
In 2015 is de 1.0 release uitgebracht.

Dus dat ligt een beetje aan je defintie. Developers laten zich over het algemeen niet tegenhouden door early builds toch

En als je kijkt naar wanneer de taal is ontstaan, dat is in 2010 geweest, dus wel degelijk meer dan 10 jaar geleden. De eerste alpha release was 2012 en dan de 1.0 versie in 2015.
Maar als je het hebt over of je de eerste bent is het beter om te kijken naar hoe lang de taal bestaat dan wanneer de eerste versie is gelanceerd lijkt me.

Hmm dat wist ik niet. Zelf nu druk met Javascript. Maar goed dat ze er nu meer focus op gaan leggen.

Zelfs (frontend) webdevelopment is mogelijk met Rust :-) https://yew.rs/docs/en/

Rust wasm! Super documentatie en hands on tutorial. Gedaan op een RPi.

[Reactie gewijzigd door MeMoRy op 9 februari 2021 12:15]

De taal (en bijbehorende tooling) is al meer dan 10 jaar uit, dus laat dat gat in de markt maar zitten.

Toch bestaat er nog wel een kip-ei-probleem; veel werkgevers twijfelen volgens mij om nieuwe projecten in Rust te starten omdat het moeilijk is ervaren Rust-ontwikkelaars te vinden. Je kunt daar tegenin brengen dat er veel mensen zijn die graag professioneel met Rust aan de slag zouden willen gaan, maar een leger aan mensen met jarenlange professionele ervaring is ook wat waard.

Ik kan makkelijker code schrijven in Go, dat net zo performed als in RUST, en heb al wat custom iterators en channeling systeem gemaakt die blocking tot het verleden maakt, en super snel is met grote maps en slices (heb nu een project draaien waar 10 miljoen items een eitje is).
RUST heb ik geprobeerd te leren, maar de syntax is soms zo vaag dat je het overzicht totaal kwijt raakt.

Het probleem is niet personeel, maar ecosysteem.

Rust bestaat volgensmij al een hele tijd

Het lijkt wel ineens heel omvangrijk te zijn geworden. Ik zat het op FreeBSD als dependency van polkit te compileren. De object base wordt +/- 18GB groot, goeiendag.

Als een van de eerste? Rust is al ruim 10 jaar oud. Deze stichting is nieuw, maar de taal zeker niet.

naast dat wat de anderen al zeggen "rust bestaat al een tijdje". Is het ook nog zo dat als jij een van de eerste bent is het moeilijk een project te vinden waar ze het gebruiken. Tegen de tijd dat je gewild bent zijn er ook andere Rust programmeurs en is het dus net zo'n "gat in de markt" als een Typescript of Dotnet developer.

Mogelijk, maar het moet je liggen en je moet werk vinden dat het gebruikt; het merendeel van de vraag naar software devs is nog altijd webapps (Java of .net, JS, etc). Rust zal hier en daar gebruikt worden, maar vnl in toko's waar C/C++ al gebruikt wordt.

MAW, als je niet in de C/C++ wereld zit is Rust mogelijk niet voor jouw.

Go is een andere die mogelijk in hetzelfde segment zit, maar dat wordt eerder voor applicaties gebruikt en ik hoor links en rechts dat het Java projecten vervangt.

Go is een andere die mogelijk in hetzelfde segment zit, maar dat wordt eerder voor applicaties gebruikt en ik hoor links en rechts dat het Java projecten vervangt.

Go zit in een hele andere markt dan Java. (Go kent bijvoorbeeld geen inheritance.) Beetje vergelijkbaar met het vervangen van JavaScript door C. Dat is iets dat je alleen doet voor hele specifieke toepassingen. Rust en Go liggen een stuk dichter bij elkaar. Hier bijvoorbeeld een switch van Discord van Go naar Rust: https://blog.discord.com/...m-go-to-rust-a190bbca2b1f

(Java wordt wel links en rechts vervangen door zijn nakomelingen: Kotlin en Scala. Maar voor deze talen geldt wel dat de basis ligt bij Java: om een goede Kotlin developer te zijn, is kennis van Java vereist.)

[Reactie gewijzigd door Cyb op 9 februari 2021 12:01]

Go zit in een hele andere markt dan Java. (Go kent bijvoorbeeld geen inheritance.)

Inheritance is een ingelukkig voorbeeld, Rust kent dat ook niet en Java had het volgens de maker ook nooit moeten hebben.

Met inheritance bedoelde ik overigens niet dat het een gebrek is van Go. Ik bedoel er mee dat inheritance volop in de OOP wereld wordt gebruikt, en dus vooral ook in Java. (Ondanks dat er situaties zijn waarin composition de voorkeur heeft t.o.v. inheritance.) Java en andere OOP programmeurs zullen het flink missen als ze naar een taal gaan zonder dat.

Waar heb je vandaag dat James Gosling heeft gezegd dat inheritance niet in Java had moeten zitten? In zie eerder het tegenovergestelde: https://www.artima.com/intv/gosling3.html

Inheritance vs. Composition: James Gosling: No, it's not too general of a question. I just wish I had some good rules because it always gets kind of vague for me. I personally tend to use inheritance more often than anything else.

Ook in moderne Java talen, zoals Scala, wordt inheritance ook volop gebruikt.
Of bedoel je het null reference probleem? Dat was niet van Gosling, maar van Tony Hoare, over de taal ALGOL W. Null reference is in veel talen terug te vinden, waaronder Java, en wordt inderdaad gezien als een bron van bugs, maar dat heeft niets met inheritance te maken.

Waar heb je vandaag dat James Gosling heeft gezegd dat inheritance niet in Java had moeten zitten?

Bedankt voor de naam, dat maakt het zoeken veel makkelijker. Ik denk dat ik het hier gelezen heb:
https://www.infoworld.com.../why-extends-is-evil.html

I once attended a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?" "I'd leave out classes," he replied. After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.

Waar ik naar verwijs is het volgende: jij stelt dat Go geen goede vervanger is van Java omdat het geen overerving ondersteunt. Maar met die argumentatie is ook Rust geen goede vervanger van C++; ook hier verlies je de functionaliteit van overerving.

offtopic:
Zowel bij Rust als bij Go is dat een bewuste keus geweest, zoals ze bijvoorbeeld ook hebben nagedacht over de syntax van functies (tail return type); we hebben door de jaren heen geleerd wat wel en niet een goed idee was, en ik begin er steeds meer van overtuigd te raken dat de ontwerpers van Go en Rust gelijk hadden toen ze overerving weg lieten. Dat heeft een paar jaar geduurd natuurlijk, ik heb jarenlang enthousiast overerving toegepast en mezelf wijs gemaakt dat dat een goed idee was. Het is dan niet makkelijk om je eigen gelijk te evalueren.

Dat is inderdaad tegenstrijdige berichtgeving van Gosling. Overigens bedoel ik dat de keuze van een taal afhangt (of zou moeten afhangen) van de specifieke situatie van een probleem. In het algemeen is zullen Java developers niet naar Go overstappen, omdat Go niet het gereedschap (bijv. veel OOP) gebruikt waar de Java developers van houden. Maar er kunnen wel specifieke toepassingen zijn, bijv. in concurrency, waar Go de voorkeur kan hebben.

In het algemeen is zullen Java developers niet naar Go overstappen, omdat Go niet het gereedschap (bijv. veel OOP) gebruikt waar de Java developers van houden.

Als je alleen maar kunt hameren is ieder probleem een spijker. Evenwel denk in niet dat alle Java-ontwikkelaars zo beperkt zijn dat ze de overstap van interfaces naar traits niet aan kunnen, maar ze zullen het misschien niet doen als het niet hoeft.

Een taal is meer dan alleen een taal. Vooral in de Java wereld is er naast de taal: een community, de tools (buiten de taal), de libraries, de volwassenheid etc. Als men alleen naar de taal zou kijken, dan zouden veel Java programmeurs switchen naar C#, omdat die daar meer mogelijkheden heeft. Het OOP gebeuren wat ik er uit haalde is slechts een voorbeeld van wat een reden zou kunnen zijn waarom in de meeste gevallen er geen switch van Java naar GO zou plaatsvinden, alleen voor specifieke projecten. De switch naar Kotlin of Scala vanuit Java, is veel aannemelijker. Daarmee wil ik overigens niet suggereren dat Kotlin of Scala beter zijn dan Java of Go. Er bestaat geen one-size-fits-all taal.

Het OOP gebeuren wat ik er uit haalde is slechts een voorbeeld

Een slecht voorbeeld, want je hebt gelijk; een taal is zoveel meer dan een syntax of een paradigma. Maar dat houdt mensen niet tegen om te switchen van taal.

offtopic:
Een switch van Java naar C# is natuurlijk niet echt een switch. Ik steun de hypothese dat C# slechts een rebranding van Visual J++ (1994-2004) is, in zekere zin een fork van Java dus.

Geen full blown inheritance, dat moet in mijn ogen ook niet. Maar Rust traits heeft wel enkele van de leuke dingen er van. Een bepaalde struct zijn eigen implementatie van Display geven zodat de println!() zodat het printen van deze struct weergeeft wat je wilt, zonder dit allemaal keer op keer te specifieren in de code.

Een bepaalde struct zijn eigen implementatie van Display

Klopt, in toepassing lijkt #[derive(...)] veel op overerving, maar de implemenatie (dmv macro's ipv function pointers) lijkt me heel anders.

Zo mooi zijn als dit zorgt dat Rust beetje momentum krijgt.

Het is een hele mooie taal maar je komt het in het wild verdacht weinig tegen. Waarschijnlijk ook omdat het wel wat anders werkt dan de meeste / populaire talen. Vooral het concept owner/borrower is erg mooi.

Erg mooi maar learning curve is steep. Het leert je zeker om ook in andere talen beter na te denken over je structuur. Rust is voorlopig mijn favoriet. Het algehele eco systeem is echt geweldig. Het is heel erg makkelijk om dependencies toe te voegen en om van elke dependency hele duidelijke documentatie op te vragen.

Ik vind het wel goed klinken dat je eerst goed moet nadenken over je structuur. Het is toch beter dan in het wilde weg beginnen en een houtje-touwtje applicatie bouwen.

Tot de tweede alinea begon leek het even goed nieuws .

Uit interesse. Wat bedoel je exact met de server header? Bedoel je die regels als x-powered-by?

Volgens mij kun je die namelijk vervangen of verwijderen (niet zeker of het met allemaal kan).

Hangt misschien ook wel van je type project af.