Microsoft is Rust:ing

Varken Microsoft eller Linux-gänget skulle ens överväga Rust om de inte ansåg att det kommit till en punkt där man kan räkna med att kod som skrivs och går att kompilera idag även kommer gå att kompilera 10-20 år från nu.

Det är sant att Rust saknar en formell språkdefinition, men man har däremot en referensimplementation som är "ground-truth" (LLVM/Rustc). Vidare, en sak man specifikt lärt sig från C++ är hur man kan lösa problemet att fixa dåliga designbeslut utan att paja bakåtkompatibilitet med existerande kod: Rust Editions.

C++ var tvungen att stava "var" som "auto" och "await" som "co_await" då man skulle haft sönder allt för mycket program om man gjort om de mer logiska namnen till nyckelord.

För Rust can varje enskild "crate" (det C++ kallar "translation unit") använda sig av potentiellt olika Rust Editions. Nyckelord och andra saker som kan bryta bakåtkompatibilitet läggs aldrig till i en existerande "Rust Edition", utan kommer i en nu och vill man använda de nya sakerna väljer man den versionen för sin crate.

Avsaknad av formell specifikation är ett problem i vissa lägen, den mest relevanta givet fördelarna i Rust är formell certifiering av kod: det är i praktiken inte möjligt att göra en sådan certifiering om det inte finns en formell specifikation man kan peka på att man följer fullt ut!

Men ISO-standard är inget krav. Java och Go är inte ISO-standarder, men de har ändå formella språkdefinitioner. C#/.Net har bara en väldigt liten del som del av ISO-standard, sen finns en standard för varje release som "bara" har en formell definition.

Standard är inte det kritiska för OS-kärnor, de vill ha stabilitet och kompatibilitet. Linux använder i praktiken inte ISO C, den använder GNU C och det har gått rätt bra ändå...

Detta är ett citat från Torvalds bl.a. kring vikten av standard i en OS-kärna

"I've been very vocal on saying the standard in this area is crap. And we're going to ignore the standard because the standard is wrong. So the same is going to be true on the Rust side."

"The more important part is that the Rust compiler needs to be reliable and stable."

Rust fångar inte bara off-by-one fel, Rust garanterar att din kod överhuvudtaget inte har några fall av "undefined behavior". Det är garantier du inte får i vare sig C, C++ eller Java, C#, Python, m.fl.

Men det hindrar dig fortfarande inte att skriva logiska buggar, så fortfarande väldigt många sätt man kan göra fel.

Värt att nämna här är att ett av de mest använda programspråken i världen just nu, Python, saknar också en formell språkdefinition. Uppenbarligen går det att skriva väldigt mycket användbart ändå...

Och det är exakt den här typen av kompatibilitet man hanterar via Rust Editions. Om 20 år kommer man fortfarande kunna kompilera och skriva ny kod i den kompilatorversion som finns då som använder sig av Rust 2015 Edition.

"Rust Edition" inte är samma sak som språkversion, man skapar bara en ny sådan om man stöter på något som är tillräckligt bra/viktigt för att motivera en bakåtinkompatibel förändring i språket.

Rust har p.g.a. av lite olika, främst tekniska, anledningar blivit väldigt populärt ihop med Web Assembly. Men mer än så är inte Rust ett "webspråk". Ovanpå det startades Rust-projektet för att vissa inom Mozilla blev så frustrerad över hur exceptionellt lätt det är att skriva race-buggar i C++ (ett exempel på "undefined behavior" i C++, något som inte kompilerar i Rust!).

Rust är väldigt inspirerat av ML, d.v.s ett av de viktiga funktionella språket. Syntaxen för macros är långt mer "matematisk" i sin design jämfört med C/C++, där handlar det om relativt enkel sträng-substituering.

Jag ser ingen poäng i att hänga kvar vid gammal junk. Men som då jag jobbat med OS-kernels i nästan två decennier ser jag definitivt värdet i stabilitet och att saker är väldefinierade!

Ser definitivt inte Rust som lösningen på allt. Tror starkt på Rust för OS och OS-systemtjänster.

Men för många typer av applikationer man absolut skulle kunna välja Rust faller mitt val oftare på Go p.g.a. av de saker man fokuserat på i den senare råkar ha ett större värde än de man primärt fokuserat på i Rust.

För microkontrollers var jag väldigt skeptiskt till Micropythons framfart, för mig var det något man programmerar i C, C++ eller möjligen Rust. Har helt svängt, Raspberry Pi Pico visar hur man med stor fördel kan kombinera Micropython för "kontrollogik" med cykel-perfekt långnivåspråk för realtids-delarna.

"Ingen" lär gå ifrån all existerande C/C++ kod som redan är skriven och fungerar väl.

Läs vad Microsoft säger: finns ingen anledning att använda C/C++ i nya projekt, behöver man verkligen egenskaperna från dessa språk är Rust det bästa valet framåt.

En kritisk egenskap i Rust är att det har bra/effektiv kompatibilitet med existerande kod/bibliotek som använder C ABI. Det betyder att man inte behöver skriva om allt gammalt.

Odefinierad variabel är inte samma sak som odefinierat beteende!
Det senare betyder: om du gör detta kan precis vad som helst hända och det är inte en bug i språket/standarden!

Går inte med mindre än att göra språket helt bakåtinkompatibelt. Det vore helt poänglöst att paja detta, till och med de som jobbar med C++ standarden har nämnt att för nya projekt är Rust ett bättre val, men C++ kommer fortsätta vara högst relevant inom överskådlig tid p.g.a. all existerande kod som finns skrivet (och det är bättre att stanna i samma språk när man lägger till / justerar en existerande kodbas).

Rust är inte bäst i alla avseende men Microsoft tycker uppenbarligen att det är bättre än C och C++.

Ha då i åtanke att Microsoft fortfarande tycker att det är bättre och mer stabilt än C och C++. Har du någon inblick i hur det ser ut för C och C++ eller du letar enbart argument emot Rust?

I vissa fall men i andra så kan det vara unspecified.

Rust is challenging to learn. Of the more than 8,000 developers responding to the 2020 Rust user survey, only about 100 identified as “expert”, and of the respondents that said they were no longer using Rust, 55% cited learning or productivity as their reason for abandoning the language.

It takes experienced engineers 3-6 months of study, supported by access to subject matter experts, to become productive with Rust. Some engineers have likened learning Rust to learning to eat your vegetables, and while many of them love it once they are productive, a lot of engineers are deciding against learning it or abandoning the effort before they become productive. The potential impact of Rust on sustainability and security will only materialize if we turn the broccoli into a brownie.

Posta C++ kod så kan vi visa hur motsvarande kan göras i Rust. Blir förvånad om det kommer vara någon relevant skillnad i komplexitet och skulle gissa att ställd mot C++ kommer Rust i genomsnitt i alla fall inte resultera i mer kod, snarare tvärtom.

Är inte genom komplexitet som Rust får sina garantier, är primärt genom sättet språket möjliggör för kompilatorn att kunna analysera hur många kontext som vid varje givet tillfälle kan tänkas ha en referens till en viss data.

Historisk har jag själv främst jobbat med C (kernel-kod och majoriteten av services runt detta) och C++ (systemnära applikationer). Det var initialt väldigt frustrerade att skriva Rust kod givet den bakgrunden, framförallt då jag är väldigt bekväm med saker som pekararitmetik och rent generellt jobba med "råa" C-pekare.

Helt sant, och det är knappast speciellt önskvärt... I det du länkar nedan är Torvalds beskrivning av C tyvärr allt för träffande:

"Yet Torvalds also saw Hohndel’s analogy that it can be like juggling chainsaws. As a long-time watcher of C, Torvalds knows that C’s subtle type interactions “are not always logical” and “are pitfalls for pretty much anybody. And they’re easy to overlook, and in the kernel that’s not always a good thing.” Torvalds called Rust “the first language I saw which looked like this might actually be a solution”"

Har skrivit en del kod som krävt formell certifiering enligt DO-178C. Är en rätt restriktiv variant av C man får hålla sig till då, är allt annat än "rolig" programmering...

Tekniskt sett hamnade C marginellt före Rust. Slutsatsen var ändå att just C och Rust var prestandamässigt/energimässigt helt jämförbara och heltalsfaktorer före andra populära språk som Java och C#, men de var också signifikant (tiotals procent) före C++.

Lite skeptisk till det sista, om enda målet är att optimera för exekveringstid så kan C++ alltid nå minst samma prestanda som C genom helt enkelt använda C-style kod. Men gissar att man i någon mån skulle hålla sig till idiomatisk kod för varje språk i detta fall.

Likt C++ är en huvudfilisofi i Rust att försöka ha "zero cost abstractions" eller i värsta fall att man gör opt-in på kostnader från abstraktion. Skillnaden är att Rust frångår detta om det skulle orsaka fall av "undefined behavior", det har i Rust högre prio än prestanda med prestanda är rätt mycket prio#1 i C++.

Och där har du en annan anledning varför Rust har värde: det går inte att få motsvarande "null pointer exception" i Rust. Även det har man designat så det kommer inte kompilera om man inte hantera ett sådant i koden (och sådan kan göra det väldigt frustrerade för de som är nya i Rust, men då ska man bara inse "skrämmande hur mycket buggar kod jag tidigare skrivet faktiskt hade...")!

Han pekar ju precis på orsaken varför C++ trots allt kommer vara relevant många år framåt, men också varför det inte går att rätta gamla missar i kompilator/språket.

"“One of the interesting aspects of programming language design is that if you succeed, you have what you did many many years and decades ago, and you have to live with it. Once you get users, you have responsibilities, and one of the responsibilities is not to break their code… There’s a few hundred billion lines of C++ out there, and we can’t break them.”"

Har den största respekten för Stroustrup, håller med om att C++ bara kan lösa flera av dess problem med externa verktyg men har definitivt inte hans tilltro på att det är möjligt utan göra C++ än mer komplex och hopplöst att fullt ut lära sig än vad som redan är fallet.

Grötigt låter mest som ovana men Rust lämnar minnesgarantier som C++ inte kan exempelvis för referenser till heap-allokerat minne för items i arrayer(kan inte korrekt terminologi här).

Kanske det men som sagt C++ kommer fortfarande vara begränsade av sin strävan för bakåtkompatibilitet.

Jag tror ärligt talat inte att du hade märkt stor skillnad i prestanda mellan C och Rust.

...och assembly slår C i prestanda så varför skriver du inte assembly? ;P Det verkar som du tror att det är någon tävling. Om du inte gillar Rust och föredrar C och C++ så skriv C och C++. Normal reaktion till @Yoshman inlägg borde vara "Skoj att folk nu får fler språkalternativ om dom vill skriva drivare".

Minnessäkerhet pga säkerhetsrisker men utöver det så tror jag att det är bra med strikta språk. Buggar vill man upptäcka så tidigt som möjligt eftersom dom blir dyrare att åtgärda ju närmre kund som dom upptäcks. Rusts kompilator är väldigt gnällig och det tror jag är en poäng som du missat. Om du nu föredrar C och vill skriva säker kod så borde du kolla MISRA C, personligen så föredrar jag att skriva Rust då. ;P

Nix. I språk som C eller C++ går sådana fel ofta inte att upptäcka vid kompilering.
Kompilatorn har helt enkelt inte tillräckligt med information.

Det går att upptäcka och rapportera under runtime, och sådant görs ibland, men då krävs att man lägger in extra kontroller i den genererade koden vilket gör den långsammare

Om det är så enkelt kan väl du göra det? Finns åtskilliga C kompilatorer med öppen källkod som du kan utgå från.
(Nej, det är inte så enkelt.)

Syntax och semantik. Jo, det är precis vad du behöver förändra.
Om du inte tror mig, bevisa motsatsen. Jag och tusentals (miljoner?) andra skulle älska att ha en C kompilator som automatiskt kunde upptäcka den typen av fel.

Skiter man i att kolla om givet data faktiskt är ett tal kan man ju göra detta.

fn read_from_stdin_c_style() {
    let int_from_stdin: i32 = try_read!().unwrap_or_default();
    println!("You wrote the integer {}", int_from_stdin);
}

D.v.s. det är en enda rad att läsa in "scanf()" style

    let int_from_stdin: i32 = try_read!().unwrap_or_default();

Man kan skicka in formaterings-sträng till try_read!() vid behov.

Givet att man i C måste deklarera variabel på en egen rad så blir det mer komplicerat där!

En funktion kan inte nollställa sina argument. Visst kan du använda ett macro för att lösa just det specifika problemet, men det hjälper ju inte alla de existerande programmen.
Och den approachen skulle ändå inte lösa följande minimala förändring av ditt exempel:

float* X = (float*)malloc(10 * sizeof(float));
float *Y = X;
free(X);
X = NULL;
free(Y);

I praktiken så är motsvarande kod mycket mer komplicerad och svårare att analysera. Olika moduler och bibliotek som kompileras separat så att en fullständig analys av koden är omöjlig att göra vid kompilering, plus användande av värden som varierar vid runtime är bara början på problemen.

Anrop + error handling