20-talets högsta prioritet på språk - Säkerhet & Snabbhet

@heretic16 , vi paratade ju just om det här i den andra tråden om Rust. Det GÅR INTE att göra statisk analys av ett program som hittar fel av den typen du tänker dig. Oavsett hur många av världens bästa programmerare du sätter på det kommer de aldrig lyckas.

Man kan i princip göra en C-kompilator som utifrån ditt C-program genererar kod som detekterar när man gör något odefinierat och då avslutar programmet eller anropar något speciell funktion eller liknande. Det finns redan verktyg av den typen, jag har för mig du skrev att du hade testat Valgrind t ex (som dock inte detekterar alla fel, men iaf några). Problemet är att om man skulle detektera allting skulle programmet bli betydligt långsammare och mer minneskrävande än motsvarande program skrivet i ett språk som är designat för det i grunden, som t ex Java som inte har pekare.

Det finns ingen anledning att välja C++ till nya program idag. Om det är program i userspace så bör man använda ett modernt programspråk med minnessäkerhet, och då är Rust ett bra alternativ. Det finns fler - Swift och Go är två andra, och det beror nog mer på vilken plattform man skriver mot. Rust är unikt just för att det kan användas i en kärna när en runtime inte är så lyckad.

Att C++ inte är så snabbt som det kanske borde vara beror delvis på att det innehåller ”allt”. Skaparen Bjarne Stroustrup lade till mer eller mindre allt som någon bad honom lägga till i språket i ett försök att marknadsföra det. Modernare språk är i allmänhet mer återhållsamma med vad de lägger till för att ge kompilatorn en chans att göra ett bra jobb.

C++ är och kommer vara högst relevant under många år framåt därför att det redan finns så mycket skrivet i C++.

I de flesta fall väger inte fördelar upp ett byte av språk om man "bara" ska utöka / modifiera ett existerande program, då är det bäst att fortsätta skriva i det språk som resten är skrivet i. Sedan finns områden där man kanske startar ett helt nytt projekt, men det i sin tur beror av någon som gör C++ till det enda vettiga valet: ett exempel är spel som bygger på en motor som är designat för C++ som Unreal Engine 4/5.

Det flera, bl.a. Microsoft, säger är: om man startar ett helt nytt projekt där man behöver ett systemspråk så finns ingen anledning att välja C eller C++ över Rust idag.

I det större perspektivet finns långt fler parametrar att ta hänsyn till. Svårt att se varför jag själv skulle välja C++ idag om det inte är ett hårt krav p.g.a. restriktioner jag inte styr över. Men det gör inte just Rust till ett självklar val bara för det är relativt lätt att producera högpresterande kod i.

Har på senare tid haft Go som favoritval i backend och low-level projekt. Det är inte lika "säkert" som Rust, färre saker upptäcks vid kompilering i Go. Men där finns andra saker som prioriterats högt och som för mig då varit betydligt mer värt att de saker Rust fokuserat på. Exempel här är att bibliotek för saker som ModBus, MQTT, GPIO-hantering (SBC) och low-level hantering av USB visat sig vara mer mogna i Go än under Rust. Om man primärt optimerar för I/O throughput (inte compute throughput) så spelar det betydligt mer på huvudfokus i Go än huvudfokus i Rust.

För OS utveckling är det rätt mycket C vs Rust i kärnan och C++ vs Rust för systemtjänster. Här lär C och C++ fortsätta finnas kvar mycket längre, det finns stora fördelar med att fortsätta använda samma språk. Men tror det är just här vi kommer se Rust etablera sig allt mer framåt.

Nu är jag ingen expert på Rust utan lekte bara med det för ett par månader sedan. Det känns väldigt komplicerat och man blir lätt frustrerad på alla kompilatorfel... Troligtvis hade jag tyckt samma sak om C++ om jag börjat med det idag dock

Iaf, man kan säga att Rust är mer "låst". Kompilatorn vet mer saker om koden än den gör i C++. Ta t ex följande i C++:

void f(unsigned int* a, unsigned int* b) {
  for (int i = 0; i < 10; i++) {
    *a += *b
  }
}

Det här ser ju ut att vara ungefär samma som

void f(unsigned int* a, unsigned int* b) {
  *a += *b * 10u;
}

Men tänk om a och b pekar på samma int? Då stämmer inte det. Kompilatorn måste då antingen göra en extra koll om a==b och göra olika saker beroende på den jämförelsen, eller låta bli att göra den optimeringen. I C++ kan a och b mycket väl peka på samma unsigned int, men i Rust kan man göra motsvarande optimering iom att kompilatorn vet att f inte får anropas med a och b pekandes på samma int (det ger ett kompilatorfel).

Ett annat exempel är

void g(const int* pa);

int a = 42;
g(&a);
print(a);

I motsvarande kod i Rust vet kompilatorn att a är 42 vid print(a), men i C++ kan man inte veta det trots att g tar en const-pekare som argument. Man kan ju ändra a genom att göra en const_cast någonstans i g! I Rust kan man därför hålla a i ett register (eller kanske till och med optimera bort det helt och hållet), men i C++ måste a sparas i minnet.

Vissa av de här sakerna kan man naturligtvis komma runt genom att titta på en lite större del av programmet istället för att bara titta på en funktion i taget. Jag vet inte hur bra kompilatorer är på det egentligen, men det går i alla fall inte för kompilatorn att bevisa såna här saker i alla möjliga situationer.

Rust är inte generellt sett snabbare än C++. Det är snabbare i vissa specifika fall, du har redan fått detaljerna kring ett sådan exempel här där underliggande orsaken kommer av skillnader i alias-regler för data som nås via en pekare.

Ur alla praktiska hänseenden är prestanda i genomsnitt likvärdigt mellan C, C++ och Rust förutsatt att man löser problemet på samma sätt.

Så uppsidan med Rust är att man får säkerhetsfördelarna, utan att offra prestanda.

Att välja något du kan istället för något nytt är en bra anledning, det finns säkert många fler

De som säger att språk Y kommer att döda/byta ut språk X är väl mest click baiters, det förstår nog de flesta. Det är samma sak som när det kommer nya JS-ramverk eller exempelvis Microsoft Blazor, de har lärt sig av sina föregångare och kanske har coola features som löser vanliga problem från sina föregångare men det finns nog ingen som tror att alla kommer sluta rakt av med de äldre sakerna då för mycket tid har investerats, både i arbetstid och kompetensmässigt.

Så om det sker en förändring är den nog mer långsam, över ett decennium eller mer.

Att påstå att Carbon skulle kunna ersätta andra moderna språk ger en grovt felaktig bild av dess syfte, så jag hoppas det inte är så många som säger det. Det är menat att vara ett bättre sätt att förvalta stora kodbaser som beror tungt på C++ och är inte något som bör användas för nya projekt. Det är absolut inte som Rust. Att Carbon på det stora hela är ett mindre ont än C++ snarare än ett riktigt bra språk i sig är tydligt från FAQn.

Källa

Varför skulle Carbon vara bättre än Rust, hur resonerar du? Jag har redan gett resonemang och källa till varför så inte är fallet nu och varför det är osannolikt att det blir så i framtiden.

Vem säger det? De som utvecklar Carbon säger det rakt motsatta, så vilka är dessa "många"? Jag kommer inte att ta ditt ord för att detta är sant, du behöver källhänvisa när du gör starka påståenden om något som inte är vedertaget.

Från din egen länk

"Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should."

Till och med de som designar Carbon helt med på att det inte är inte en perfekt lösning, utan en lindring i det fall man sitter så djupt i träsket att det inte är realistiskt att komma ut ur det.

NSA har (bl.a. till Bjarne Stroustrup förtret) kommit till samma slutsats som bl.a. Microsoft

"NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory-safe language when possible"

Alla inser att det finns extremt mycket skrivet i C och C++ och att det inte är realistiskt att skriva om all den koden i något annat. Men de flesta är ändå införstådda med att om möjligheten finns gör man bäst i att välja något annat än dessa språk idag.

Hur mycket C++ och saker som försöker vara kompatibelt med C++, som Carbon, än lyckas rätta till existerande problem kvarstår ett gigantiskt problem: ska man vara bakåtkompatibel blir alla nya säkrare finesser "opt-in", d.v.s. det finns inga garantier för att ens ny kod utnyttjar eventuella förbättringar (det skrivs tyvärr fortfarande en del ny C++ kod som ur alla praktiska hänseenden är pre-2011 style, något även Bjarne är smärtsamt medveten kring "Unfortunately, much C++ use is also stuck in the distant past, ignoring improvements, including ways of dramatically improving safety.").

Men just därför att det finns så många fall där C och C++ redan är är en så central del kommer båda dessa språk finnas kvar under överskådlig framtid. Det ändrar inte att det finns bättre alternativ i de fall något annat är ett realistiskt alternativ.

Som du redan har fått förklarat för dig många gånger:
Därför att en C++ kompilator inte kan upptäcka alla instanser av sådant, och skulle den refusera alla program som kanske innehåller en minnesläcka eller en överindexering (dvs program där kompilatorn inte kan bevisa att sådant inte förekommer) så skulle den stora majoriteten av existerande C++ kod inte kompilera.

Det finns garanterat utrymme för förbättringar, men för att kunna ge några vettiga garantier så måste språket ändras så pass mycket att bakåtkompatibilitet ryker och vi i praktiken får ett nytt språk.

Om du inte tror på oss, så försök fixa problemet själv istället för att bara hålla på och jiddra om att det borde gå. Även om du kommer att misslyckas så kommer du förhoppningsvis att lära dig en massa på vägen.

Nu vet jag inte vad Bjarne Stroustrup sagt om det här, men min spontana gissning är att han vill att all ny C++ ska skrivas på ett visst sätt, t ex inga new/delete, regler för när man får spara undan en pekare etc. Det blir så att säga ett subset av C++. Följs de reglerna kanske kompilatorn kan bevisa vissa egenskaper på programmet, t ex att ingen use-after-free förekommer. Det borde vara möjligt. Men man kan inte analysera gammal kod som inte följer de nya reglerna för att bevisa varken att den uppfyller egenskaperna eller inte uppfyller egenskaperna, av anledningar som redan förklarats flera gånger.

Nej, det är inte fel på koden. Koden är skriven enligt spec idag. Det du vill är att kompilatorn skall analysera koden som kommer in och förhindra den här typen av fel. Det Erik_T skriver är att det enda sättet att åstadkomma det är att också blockera en hel massa kod som inte har några problem alls. Då är det inte längre C++, utan ett C+++ eller nåt. Det är i sig inte svårt att göra ett programspråk som liknar C++ men är minnessäkert, men då är det inte C++. Om man skall gör något nytt så kan man lika gärna fixa alla andra korkade grejer i C++, och så blir det ett av de många språk som växer idag. Rust är ett av dem.

Just det här problemet är lite speciellt i att vi faktiskt vet att det inte går att lösa genom att bara analysera koden innan den körs. Det finns matematiska bevis på det. Hade det inte varit så, hade någon säkert gjort ett C+++ som bara är minimala förändringar för att göra det säkert. Istället spenderar man mycket mer tid med att göra nya programspråk, för det finns inget lättare sätt.

Strostrup är allt annat än neutral i frågan. Han har ryckt ut till språkets försvar, för antagligen är språket precis som han vill ha det. Han måste vara medveten om kritiken mot språket, och märker att säkerhetsargumentet är den kofot som fungerar när det gäller att få den stora massan att byta bort hans språk. Jag upplever att han mest snackar för att vinna tid. Problemet är olösligt, vilket han säkerligen vet.

Det behöver inte vara något fel på koden (fel då i betydelsen att koden fungerar annorlunda än avsett), men det kan vara omöjligt för kompilatorn att bevisa att den inte innehåller vissa typer av fel.