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

Det riktiga problemet kring OP's frågeställning är snarare;

Bör vi verkligen acceptera en lägre kompetensnivå inom IT-utveckling?

För det är det det handlar om. C++ är från början och i grunden ett lågnivå-språk. Även om väldigt många arbetar för att göra C++ till ett högnivå språk, så kommer dom aldrig att nå hela vägen fram. Jag skulle snarare säga att all extra komplexitet dom lägger till i språket med åren gör det mindre säkert, snarare än tvärtom.

Vill du ha ett högnivå språk, använd ett högnivå språk. Har du rätt kompetens kommer du skriva ren, säker och stabil kod oavsett ditt val av språk.

Tål att tilläggas, samtliga högnivåspråk och deras runtime körs förmodligen på mjukvara skrivet i ett lågnivå språk, och även dessa kan skrivas av totalt inkompetenta "techbros", som i sin tur skulle göra högnivåspråket lika osäkert och ostabilt.

Våga förvänta er mer av utvecklare. C och C++ är båda i grunden fantastiska språk, som man med rätt kompetens kan utföra mirakel i.

Själv använder jag både Dart, Java, och C i mitt dagjobb. Kan säga att C-lagret är det mest stabila och robusta av hela kodbasen, förmodligen för att övriga består av mycket högre komplexitet, och är mer beroende av buggiga ramverk, bibliotek, runtimes osv.

Sen att C-lagret också presterar fenomenalt mycket snabbare än någon annan mjukvara skrivet i företaget är väl kanske bara en bonus?

De flesta. Områden som forskning, automotive(bilar), sjukvård, spel, byråkrati, saker med hög prestanda och så vidare

Där separeras i princip alltid domänen från grundläggande kod

Det gjorde jag inte När det kommer till programmering så står det mest en massa smörja på wiki men jag fick upp den sidan när jag sökte

C++ är "allt" (multi-paradigm)

haha, ok
problemet med de andra språken är att du måste installera en hel hög med komponenter och dessa komponenter är normalt skrivna i C/C++

Du kan göra det motsatta med, friheten gör att man kan göra mycket. Exempelvis köra av vägen men också köra väldigt snabbt. Hur C++ hanteras beror på utvecklarna.
Det C++ inte är bra på är det sista lagret (helst om utvecklare skött sin uppgift) som tar hand om domänspecifika operationer. Det tar tid att uppdatera kompilerad maskinkod från C/C++

Om man skippar all ny idioti i C++ ("smarta" pekare osv), och använder det som många erfarna använder det; Som C med klasser, så blir det ett väldigt bra språk i sin egen ära.

Man måste dock ha samma tänk som man har i C; Full koll på minnesallokeringar, pekare, cache-vänlig data layout, osv. Därför menar jag att C++ faktiskt är ett lågnivå språk. Man kan slänga alla möjliga typer av komplexiteter in i C++, och hävda att "råa pekare är farliga och obsolete!", men det ändrar inte riktigt verkligheten.

Absolut är det lättare men det kommer alltid finnas nivåer i hur saker kan göras. Vill man bli skicklig utvecklare och göra bra saker så är det inte så mycket annat att välja på än C++. Och några få utvecklare där som behärskar språket slår det mesta, de producerar bättre saker än vad kanske det 10 dubbla gör i andra språk (jag vet att detta retar.....) men har man exempelvis sätt dataorinterade lösningar och vet hur lösningar går att få återanvändningsbara är det inte så konstigt.
Andra språk som snabbt kan skapa saker har ju oftast en grund skriven i C/C++ som gör "jobbet" även om utvecklare i exmpelvis nodejs tror att det är javascript som är så bra

Eftersom vi disktuerar på sweclockers så är spel säkert bekant och det är mycket vanligt att spel "embeddar" lua och då görs sista lagret (domänen) i lua. Spelplaner och annat som hela tiden ändrar sig passar inte C++ för.
Ofta kan sådant här kallas för metadata, nästan alla C++ applikationer läser in metadata som har konfigurerar koden för hur den skall bete sig. Desto mer flexibilitet desto mer "avancerad" metadata och ibland går det över till skriptspråk som lua eller python.

Om du inte menar C eller assembly nu, så är du ute och cyklar litegrann Vill du pressa prestanda från hårdvaran i någon form alls (cutting edge spelutveckling, signalprocessering av stora mängder data, embedded programmering osv) så är det i princip ett skallkrav att använda C/C++ (i vissa fall Rust, även om jag inte är ett stort fan av det språket)

Hur då?

Vad är det i Modern C++ (säg version 17 eller 20) som du tycker är svårt / problematiskt / onödigt komplext?

T.ex. varför är raw pointers bättre än std::unique_ptr? (Vilket någon annan i tråden hävdade)

Så varför använder Volvo, BMW, GM och de andra stora biltillverkarna C++ 14/17 för bl.a. förarassistanssystem som har semi-hårda realtidskrav? Vad gör C++ till ett dåligt val här?

Dom försöker ändra C++ till något det absolut inte är; Ett högnivå språk. Det blir högre komplexitet, helt i onödan, och således ett sämre språk att jobba med.

Raw pointers (eller bara pekare) är vad C++ alltid har haft, och det finns inget fel med det. Det är lågnivå av en anledning och krävs en del kompetens för att inte göra misstag, men det är så det är tänkt från början. Unique_ptr är en krycka för n00bs som vill hävda sig vara grymma programmerare. Det tillför ingenting annat än onödig komplexitet och en inbillad prestige.

Istället för att fråga varför pekare är bättre än "smarta pekare", ställ dig frågan varför behövs ens "smarta" pekare? Bortsett från shared_ptr och weak_ptr som kan vara användbara (dock i min åsikt så bör man oftast själv implementera sådan funktionalitet om man behöver det, då shared/weak är extremt generiska implementationer).

Det finns också en mörk sanning kring utvecklingen av C++, som involverar en trend av mental ohälsa som påverkar hela industrin negativt (som även påverkar C++ consortium). Detta är dock inget jag vill vidareutveckla i tråden, men eftersök själv i ämnet om du är nyfiken.

Försök inte laga något som inte är trasigt, säger jag bara

Embedded kännetecknas nästan alltid av begränsade systemresurser, men också möjligheter för hårdvaruspecifika optimeringar. Att använda något annat än ett native språk blir då ganska slössamt.

C och C++ hanterar tunga beräkningar precis lika bra som Fortran, som också är ganska nischat idag.

Rent kodmässigt blir det högre komplexitet. Det är ett extra lager ovanpå vanliga pekare, med tillhörande regler, rekommendationer osv. Det tillför dessutom ingen konkret funktionalitet, mer än ett påtvingande programmerarbeteende, som inte alltid är positivt.

Google rekommenderar dessa stödhjul, eftersom att Google investerar mycket i billig arbetskraft i bulk, och som du säkert vet så får man vad man betalar för (inkompetenta programmerare). I google's fall så fungerar dessa stödhjul till att minska antalet buggar i koden, eftersom att en stor del av deras programmerare är inkompetenta techbros.

Smarta pekare finns endast till för att kompensera för osmarta utvecklare. Och dom gör i princip alltid kodbasen sämre, om inte annat för att det ökar komplexiteten i koden.