Varför finns det alltid en "C++ Killer"?

Det är väl precis som allt annat som är populärt, folk börjar spekulera om en "dödare". Känner du till spelet WoW har du säkert hört talas om alla WoW-killers som kommit ut.

Anledningen till att många implementerar C++ är ju för att det är relativt enkelt att göra, det finns många referensimplementationer och mycket källkod och bibliotek att tillgå.

Sedan är ju C ett språk som är basal i sin assemblergenerering, med ett minimum av kollar under körningen. (Nära metallen som det brukar benämnas) Sådant ger prestanda som är välbehövlig på inbyggda system. Alla nya språk försöker lösa diverse problem hos dessa oldtimerspråk, men till syvendes är det prestandan och kostnaden som räknas. Det kommer alltså alltid att födas nya språk med mera finesser, men eftersom de genererar mera kod så hålls de än så länge tillbaka. Det är ju lite skillnad på om det är en DVD för 499:-- (inkl 25% moms) eller ett kärnkraftverk där du kan överdimensionera processorn och dra nytta av alla språkfinesser.

Mycket av detta har även att göra med hur välskrivna kompilatorerna är. Språk som delar backend/optimering tjänar ju på detta. Sen har vi ju andra som gör på sina egna sätt, är det rust som kompilerar koden minst två gånger för att försäkra sig om att binären blir identisk?

Det kommer alltid uppstå utmanare till allt inte enbart programmeringsspråk. Som människor så fungerar vi väldigt olika och om något inte resonerar med hur du tänker eller vill lösa problem, då uppstår behov för alternativ. Personligen tycker jag inte att man ska motsätta sig detta, om man inte utmanar status quo så kommer man aldrig se utveckling.

Precis som för andra områden så sker det utveckling av programmeringsspråk och nya paradigm/koncept introduceras som förenklar för utvecklare. C och C++ har funnits ett tag och det är svårt att göra förstora förändringar i språken utan att skapa svårigheter för existerande projekt, ska man stödja den nya versionen för features eller behålla bakåtkompatibilitet?

Rust har fått mycket uppmärksamhet eftersom språket är konstruerat på ett sådant sätt att det kan erbjuda garantier gällande vanliga problem i C (Jag är oklar gällande C++ eftersom jag inte kodar C++). För att Rust ska kunna lämna dessa garantier så krävs ibland annoteringar för att hjälpa kompilatorn och det kan ibland upplevas som komplicerat.

Zig sägs kunna lösa en del av komplexiteten som Rust har med sina annoteringar. Kompilatorn verkar exempelvis kunna räkna ut minneslivslängder på ett automagiskt sätt. Min uppfattning är att Zig inte explicit tagits fram som en ersättare till Rust utan ett alternativ till C och hamnar i samma kategori som Rust. Jag kan förstå varför man kan se Zig som en ersättare till Rust med det förenklade utvecklingsförfarandet. Det tåls att nämna att jag sett Zig program som segfaultar något som jag ännu inte sett i Rust dvs min uppfattning är att Zig inte lämnar samma starka garantier som Rust.

Dom kan teoretiska ersätta C och C++ men det krävs att språken anammas av existerande community. För många projekt är det inte relevant eftersom det skulle kräva en omskolning av majoriteten av projekt-communitiet följt av en omskrivning från scratch som antagligen kommer introducera allvarligare logiska fel.

SoC-tillverkare vill sikta på så stor skara utvecklare som möjligt. Genom att erbjuda C så täcker dom upp för C och de flesta andra språk som kan interface:a mot C (C++, Rust, Zig, Go, Python, Erlang, Java osv).

För att avsluta med ett tips. Jag brukar se på språk som verktyg. Du ska självklart välja det språk som du är bekväm med eller ett språk som intresserar dig dock är det kanske bra att lära dig några olika språk för olika syften. Typ ett lågnivå, ett högnivå, ett skriptspråk, ett concurrent-språk. Detta är dock en balansgång där man ska vara lite försiktig med att bli för spretig, annars riskerar man att sakna djupare förståelse för språken.

Beror på vilka brister man fokuserar att fixa.

Go är på en lång rad sätt bättre än C och C++, ändå är det ett långt enklare språk än C++ och skulle vilja hävda att det även är enklare än C (då har jag ändå ~30 års erfarenhet av C och C++, mindre än 1 år med Go, skulle ändå aldrig vilja gå tillbaka till C/C++ i de fall jag nu använder Go). Fast en av huvudmålsättningarna med Go är just att det ska vara enkelt då man identifierat användare av "stora komplexa språk" som ett stort problem i projekt med många iblandade och stor kodbas.

Det som är spännande med Rust är att man gett sig på att nära nog lösa en av den värsta klassen av buggar vi har i IT-världen. Och man gör det i ett språk lämpligt ända ned till OS-kernel utveckling, d.v.s. verkligen ett "system level" språk.

I Linux jobbas det redan för att möjliggöra bl.a. drivrutiner i Rust. Vad jag förstår jobbar Microsoft med liknande för Windows.

Värt att notera att ingen av dessa OS använder C++ i kärnan. Det är fullt tekniskt möjligt att tillåta det, eller i alla fall delvis, finns OS som tillåter en relativt stor delmängd av C++ att användas i OS-kärnan. Rust (och vad jag förstår även nämnda Zig) har en väldefinierad/standardiserad delmängd som fungerar i t.ex. OS-kärnor och mikrokontrollers, använder man C++ blir det lite upp till var och en att definiera denna delmängd.

Så även detta är ett tillkortakommande som "C++-killers" fixar, men här finns försök till standard även för C++, t.ex. detta och detta

Kostnaderna för mjukvaruproblem blir dyrare ju närmre slutanvändaren som dom upptäcks. Min uppfattning är att man röker ut betydligt fler problem innan programmet ens kompileras i Rust, jämfört med andra språk. Rust är krångligt när man måste guide:a kompilatorn gällande exempelvis livslängder för minne. Syntax är alltid konstig i nya språk. När juniora utvecklare börjar med Python så tycker dom att det är svårt att tillfredsställa interpretern för att dom har dålig koll på indentering.

Den första Rust-drivaren har landat upstream i Linux om jag inte är helt fel på det.

Om man ska ge en kommentar om Go vs Rust så i Go valde man att designa ett simpelt språk som är lätt att lära med få features. Man missade inledningsvis att implementera något i templating-kategorin av features dvs macros/templates/generics. Nyligen har generics introducerats i Go men det kom med en hel lista begränsningar (några av dessa löstes i senaste releasen) men detta ihop med prestandadippar pga GC gjorde att jag valde om från Go till Rust. Samt att jag pysslar mestadels med embedded och C så Rust passar min profil bättre.

Har kikat rätt grundligt på implementationen av Rust och Go för ett par år sedan, detta för att lägga in stöd för dessa i ett RTOS. Slutade med att endast Rust togs med (har även implementerat C11 och C++11/14/17 standardbibliotek för samma OS).

Är det något som är unikt/bra med Go, förutom att det är ett så enkelt språk att lära sig, är den otroligt genomtänkta modell man använder för att schemalägga "go-rutiner" över tillgängliga CPU-kärnor.

Men precis som du skriver: Go har samma problematik som alla språk med GC, inte en bra match om man är ute efter bra realtidskrav (och var det som gjorde att Go skippades efter "proof-of-concept" delen).

Däremot fungerar Go super för embedded förutsatt att man bara har "mjuka" realtidskrav. Är precis sådana saker jag använder Go till i nuläget (ihop med fältbussar som SPI, I²C, RS485 etc). Go:s sätt att implementera interface är faktiskt riktigt smidigt när man bygger APIer mot HW-register . Men självklart är Go:s riktigt stora styrkor i mer traditionella "backend" system och/eller egentligen allt där man har mycket samtidig I/O att hantera.

Template (som kom i 1.18 våren 2022) känns som de lika gärna kunde skippat. Är några enstaka saker som blir lite trevligare, men är väldigt sällan man verkar behöva det om man skriver idiomatisk Go. Är fullt möjligt att programmera "funktionellt" i Go, finns även ett gäng bibliotek för detta. Men håller med de som säger: but why? Det finns bättre språk om man vill ha den stilen, en av Go:s styrkor är att koden är lika explicit och lätt att följa som C (till skillnad från t.ex. C++ saknar dessa "implicita" anrop).

Gillar Rust, det är trevligt efter man kommit över den initiala frustrationen med att bråka med "borrow-checker". Men har insett att jag underskattat de egenskaper man prioriterade när Go designades. Var först när jag verkligen började skriva Go-kod som det blev uppenbart hur rätt tänkt "enkelheten" är.

Orsaken till att det blev Go initialt var för att ett bibliotek jag behövde för low-level stuff på RPi4 (saker som använder GPIO-pinnarna) visade sig vara "abandonware" i dess C++ form, C++ var det spåk jag tänkte använda. Visade sig att Go hade ett bibliotek för motsvarande funktioner med bra dokumentation och aktiv utveckling (+ att jag då kört Advent of Code i Go en gång och valde därför att köra det 2022 också).

Just fokus på specifika saker tror jag är viktigt om man ska ha en poäng som språk. Rust har ju sin "killer-app" med att saker som minnesläckor och, än viktigare, race-condition orsakar kompileringsfel (hur brutalt bra är inte det för t.ex. drivers?). Go har sin enkelhet och klassledande "concurrent programmering" modell (async/await som andra annamat, inklusive Rust, är en katastrof jämfört med det Go/Erlang har). Zig:s fokus på portabilitet och hur man kan opt-in i bara de delar av standardbiblioteket som man faktiskt behöver kan ge det en vettig nisch

Tänk Fortran då som har funnits i över 60 år. Det har förenklats och ändrats en hel del genom åren men används fortfarande. Snacka om seglivat.

Har förstått det på samma sätt . Vet hur mycket man planerar lägga in i språket kring async, finns ju fördelar med att hålla saker som bibliotek.

Tokio gör väl ungefär ett så bra jobb man kan göra givet förutsättningarna, d.v.s. att man i grunden har just OS-level trådar man jobbar med (så samma som async i C++, C# etc). Det fungerar inte att ha massiv mängd OS-trådar, varken schemaläggningen eller mängden minnen gör det realistiskt att hantera 10-tusen och än mindre 100-tusentals trådar.

Problemet med async/await modellen är att den leder till system som är exceptionellt svåra att förstå (d.v.s. förstå runtime beteendet) och därmed debugga. Rent prestandamässigt fungerar tekniken, den är bara väldigt svårt att debugga. Använde just Tokio i det lite större Rust projekt jag jobbat med, det var väl den mindre trevliga upplevelsen av Rust (fanns andra delar / processer i det projektet som tack och lov inte körde async).

Det som är unikt med Go (och som jag förstår det även Erlang, har bara gjort småsaker i Erlang + läst en del om implementation) är att stacken kan växa dynamiskt (vilket inte är möjligt i C, C++, C#, Java, Python, Rust, etc). De flesta tasks (Go-rutiner / Erlang processer) kommer klara sig med en stack på bara några 100-tals bytes, så är minnesmässigt inga problem att ha 100-tusentals sådana!

Kan inte detaljerna kring hur Erlang schemalägger sina processer (i alla fall inte på den nivå jag satt mig in i Go:s modell). Go har även här en modell som utan problem hantera 100-tusentals "go-rutiner". Något som är helt orealistiskt med pthreads (även om man hade tillräckligt med RAM skulle prestanda bli horribel).

Dessa två saker sammantaget: man slipper hålla på med "asyn/overlapped I/O" som gör det svårt att riktigt se vad som händer. Istället kan man köra helt vanlig blockade I/O i dessa taskar (vilket i debuggern också gör saken enkel då varje go-routine/erlang-process har en egen call-stack, inte en kompilatorgenererad tillståndsmaskin som är fallet för async/await).

Det är en (av flera) killer-app för Go/Erlang.

Killer-app för C och C++ är idag mängden programvara/bibliotek som redan finns och är skrivet i dessa språk. C har också att det är "standarden" för egentligen allt annat när man kommunicerar mellan olika språk/ramverk. Sen är ju C och C++ möjliga att skriva riktigt snabba program i, dock inte fundamental snabbare än t.ex. Rust och Fortran (och inte långt efter kommer Swift, Go, Java, m.fl).

Har bara läst Fortran-kod, aldrig skrivit något. Men även här finns ju en "killer-app". Semantiken hos Fortran gör det långt enklare/effektivare att utnyttja SIMD-instruktioner för saker som matris-operationer jämfört med C/C++.

Så Fortran kan vara klart snabbare än C/C++ för vissa områden, områden som är tillräckligt viktiga/vanliga för att Fortran ska kunna leva vidare. Finns ju lite varianter av C/C++ som kommer runt problemet, Nvidias CUDA är en, Intels ISPC är en annan. Dessa är ändå inte C eller C++, de är bara "C/C++-like".

Varken CUDA eller ISPC ersätter C eller C++, det är inte alls tanken. Utan de hanterar bara en rätt specifik nisch, det långt bättre/mer effektivt än vad som är möjligt i C eller C++.

Någon som har lite insikt i hur pass väl "ren" Fortran fungerar för att ge riktigt bra SIMD-kod via en kompilator? Vet egentligen inte mer än att Fortran hanterar just detta klart bättre än C och C++.