C++ och dess framtid att programmera minnessäkert - Hur går utvecklingen?

Om man tar en sample-size på 1 kan man "bevisa" exakt vad som helst i stort sätt var som helst... Enda potentiellt relevanta Zed tillför är att det (vad jag får fram när jag läser om projektet) visar att en sak Rust kan användas som är, likt bl.a. C och C++, högpresterande applikationer. Aldrig använt Zed, men det som lyfts fram är att det är en text-redigerare som håller väldigt hög prestanda även när fil(erna) som redigeras är gigantiska.

Vill du se exempel på idiomatisk Rust som också visar hur man dels kan skriva inom ramen för, just nu, bästa tänkbara skydd mot minnes-osäker kod kan du kika på t.ex.

https://github.com/tkaitchuck/aHash - Hashset/map som är API kompatibel med den i std:rust, fast med klart bättre prestanda

https://github.com/serde-rs/serde - väldigt bra exempel på hur "traits" kan användas väldigt ortogonalt mot andra saker ett bibliotek gör där serde "bara" tillför möjligheten att serialisera/deserialisera dina datastrukturer till JSON, YAML, CSV, Pickle, eller vad det nu må vara. Det på ett högt effektivt och minnes-säkert sätt

https://github.com/rayon-rs/rayon - min favorit då det man uppnår här är på flera sätt helt makalöst, fångar data-race compile-time. Finns få saker som är svårare att få rätt i modern programmering än just concurrency-problem.

Alla dessa tre är saker som inte är del av standardbiblioteket, men som alla är väldigt populära "crates" som alla har 100-tals miljoner nedladdningar. De är alla också utvecklare med idiomatisk Rust.

Ett uttalande som "tar betydligt längre tid att utveckla i X jämfört med Y" saknar väldigt mycket kritiskt kontext. Klart det är sant om några som primärt jobbat med X testar att göra något av liknande komplexitet i Y, innan de lärt sig Y kommer det vara svårare/långsammare.

Sen kommer "problemet" som diskutera här från observationen att C++ (och även C) står för en förkrossande stor andel av en specifik klass av buggar. Tror det tar rätt mycket längre tid att få C++ till samma kvalité på den punkten som motsvarande Rust, om det ens är praktiskt möjligt (vilket är det Bjarne et.al. vill visa att det är, för annars kommer C++ bli portat från att fler områden).

Skulle i.o.f.s. hävda att Rust har en liten särställning i raden av "språk som ska döda C++"...

Det är sant att lite väl många sagt något likt ovan. Ingen har så här långt "dödat" C++. Givet hur mycket som redan är skrivet i C++ och kommer fortsättas användas under överskådlig tid lär inget döda C++ (inget har ju lyckas döda Cobol så här långt...).

Man kan se det från en liten annan vinkel: det är rätt många områden där C++ skulle varit ett självklart val för de flesta under 90-talet som idag i praktiken helt är ersatt av Java och C#. Så för en lång rad områden "dödade" Java/C# C++, men samtidigt finns områden där Java/C# inte var en bättre lösning.

Samma med Go. Google skapade Go specifikt för att ersätta fall där de vid tidpunkten använde C++, men där de såg stora skalbarhetsproblem med C++ både p.g.a. av dess extrema komplexitet (inte positivt när man har väldigt stora och många team) samt den enorma storleken på kodbaser (kompileringstiderna var direkt horribla, mem:et är ju att första versionen av Go skrevs medan de 3 skaparna väntade på att deras C++ projekt skulle kompilera klart).

Go har sedan haft betydligt inflöde från Python, C# och Java än från C++. Nischen detta språk fyller är microservices, molntjänster och C++ har man nog primärt "ersatt" (i.e. är nog det vanligare valet idag) som språk för CLI-verktyg.

Det unika med Rust är att det nog är första språk som har ett nära 100 % överlapp med C++ i att vara topp-valet för de nischer där C++ idag fortfarande är topp-valet. Tror det är något gör att vissa inom C++-världen ser en större rivalitet mellan dessa två språk än vad man sett innan.

Men inte ens Rust lär "döda" C++. Däremot kan det ju bli en rätt snabb minskning av C++-användning om så viktiga institutioner som USA och EU mer eller mindre säger: ni får ha väldigt bra på fötterna kring varför C++ alls bör användas om organisationer vi direkt hanterar är kunden. Är väl just den delen Bjarnes "call to action" riktar sig mot.

Jag arbetar professionellt med C++ och Rust kodbaser sedan runt 7 år. Specifikt en [rutt-planerare](https://github.com/valhalla/valhalla) där det krävs absurt mycket rå pekararitmetik för att snabbt kunna expandera grafen över vägnätverket.

Vi har också börjat skriva nya projekt i Rust. Precis som Amazon, Google och Microsoft anser jag att man inte ska starta nya projekt i C++. Punkt. Vår effektivitet i Rust projekten är så mycket högre, då kompilatorn fångar väldigt mycket fler problem och den generella utvecklarmiljön med cargo och annat funkar så mycket bättre. C++ koden är generellt en lång serie av Undefined behaviour buggar, segfaults och andra Heisenbugs.

Vi har till och med ett stort projekt där vi bygger C++ ruttplaneraren som ett C lib och laddar in till ett Rust program med FFI för att kunna återanvända delar av C++ koden i vårt Rust program. Detta tror jag kommer bli mer och mer vanligt. Att man tar äldre kodbaser som inte kan migreras till andra språk speciellt enkelt och börjar bygga nya system runt dem i mer moderna språk.

Att göra dagens version av C++ minnes-säkert enbart via kompilatorn är bevisat omöjligt. Det i sig är inte konstigare än att vi kan säga: har du ett underbestämt ekvationssystem kan du inte få fram en entydig lösning.

Implikationen av ovan är tyvärr också att det inte finns något sätt att lösa den detaljen med mindre än att göra icke-bakåtkompatibla förändringar. I det läget är det väl rätt naturligt att det inte är självklart hur vägen framåt ser ut.

Möjlig kritik mot ISO-kommittén är att man eventuellt hamnar i att inget görs till C++26 kring detta. Samtidigt måste man också ha med sig att det som en gång hamnat i standarden är väldigt svårt att få bort i praktiken, så ändå rätt att inte bara slänga in första bästa förslag.

Men samtidigt är det lite osäkert hur bråttom det är. Om "under attack" mer bör likas vid en krigssituation bör det hanteras annorlunda, i det läget är icke-beslut det sämsta man kan göra. Vilket beslut som helst, bara det görs ut utförs, är bättre.

Oavsett vad man gör kommer C++ används under lång tid framöver. Huvudfrågan är kanske vad som har störst värde för de som idag använder C++: att försöka utveckla språket så det framåt fortsätter vara relevant för nya utmaningar, eller fokusera på att det som redan är skrivet får en så bra/stabil miljö som möjligt och acceptera en tynande tillvaro i green-field projekt. Båda har för- och nackdelar.

Kan tycka att det senare inte är så dåligt alternativ. Det finns ju redan fullgoda alternativ framåt.

Finns väl egentligen kanske 3 huvudgrupper av C++ användare
* de som följer med utvecklingen och idag helt anammat "modern C++"
* de som till största del stannat på C++98 (och lite är de som Bjarne verkar anse vara "problematiska")
* de som aldrig ens kommit ISO C++, utan använder C++ som ett "bättre C"

Inser att jag själv nog främst nästan bara kommer använda C++ i den sista kategorin framöver. Är där man hittar användning i mikrokontrollers och liknande. Tycker C++-användningen här är ett steg upp från "ren" C, men samtidigt är det inte mycket mer än "C with classes" man jobbar med då.

C++ som språk är underdefinierat. Du kan inte fixa grundläggande problem i efterhand i en kompilator. Det är därför du har en stor delmängd av C++ utvecklare som helt enkelt inte tror på dessa uttalanden från Bjarne.

Hmmm, undrar hur många gånger jag varit med om samma retorik.

Minns när VB (visual basic) var så poppis (det första så kallade RAD verktyget). Att skriva windows program i C/C++ var ju gigantiskt svårt medan de i VB kunde dra och släppa in saker grafiskt utformade miljöer medan koden genererades. De var otroligt produktiva i en månad, men det sedan tog allt längre och längre tid.

Java hade samma retorik, allt blev så mycket enklare. Gick fort i början tills efter ett tag när hastigheten minskade och minskade drastiskt.

Micorsoft har släppt ett antal verktyg för att generera applikationer under årens lopp, nästan alla har pensionerats

Det kommer bli samma resultat nu, skall något skala och leva länge måste man förstå och bygga en stabil grund.

Stämmer inte, volvos problem ligger i att det inte är ett mjukvaruföretag, de kan bygga bilar. Alla företag som måste ställa om sitter på en hög med människor med höga löner som inte vill bli av med jobbet. Och de kan inte lära nytt. En mycket svår resa

Volvo måste lära om, det löser de inte med rust (tvärtom)
När så många människor är oroliga för sina jobb blir de rädda för att göra fel och vågar inte göra något alls eller så får fel personer för mycket att säga till om. Finns en del som sett hur Volvo utvecklar och vad jag vet finns det gott om "intressanta" historier