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

Blandar du inte ihop "concurrency" och "parallellism" nu?

Parallellism är inte speciellt vida utbrett i servers då dessa generellt sett är främst I/O-begränsade.

Concurrency: hantera flera saker potentiellt överlappande, kan göras även om man bara har en CPU-tråd!!!
Parallellism: köra flera saker samtidigt, kräver multipla CPU-trådar.

De flesta språk har stöd för båda. Men ser vi idag också specialisering där Go är ett exempel på något som är riktigt bra på "concurrency", det stödjer också parallellism men det är inte fokus och effektiviteten är inte superbra.

Rust har vi t.ex. Rayon väldigt bra stöd för "parallellism". Det har också stöd för "concurrency" via t.ex. Tokio, men för egen del föredrar jag absolut Go över Rust för just "concurrency".

I standard C++ stöds "parallellism" via saker som execution policies. Concurrency stöds via coroutines. Trådar, så som definierad av POSIX-threads, är tyvärr en rätt illa designad abstraktion då det blandar ihop dessa två koncept helt och hållet (vilket inte kan beskyllas på inkompetens utan mer en konsekvens av dess ålder, initialt var det främst "concurrency" då multicore CPUer var väldigt ovanligt då).

C# tog rätt mycket helt över det man på 90-talet skrev med C++ och MFC. Senare tog C# även över det som tidigare skrevs i VB, bl.a. då Microsoft tvingade kunderna till det via VB .NET som mer var C# med VB-syntax än "gamla VB".

Just de specialanpassade applikationer som många konsulter jobbar med är också ett exempel på sådant som på 90-talet främst skrevs i C++ och mindre del även skrevs i VB.

Javas "compile once, run everywhere" var ju länge ett meme, i praktiken fungerade det förvånansvärt dåligt och sanningen var mer "compile once, debug everywhere"... Hade detta fungera hade Go nog inte alls fått den spridning de fått på just molntjänster, för DÄR har man hittat rätt recept (man måste kompilera för den explicita målplattformen, men det kan göras "everwhere" och resultatet fungerar även i praktiken, inte bara i teorin).

Exakt! Jag lämnar nu tråden. Det är samma gamla diskussion som alltid kommer upp. C++ utvecklare som inte vill eller ännu inte lärt sig modernare språk mumlar om hur C++ är bäst och nya verktyg inte egentligen är bättre, bara man skriver C++ "rätt".

Men stora organizationer som Google, Amazon, Microsoft och usas regering säger nu att C++ inte bör användas i nya projekt. Jag har själv sett hur mycket effektivare våra team är som jobbar i Rust än C++.

De utvecklare som lär sig de nya verktygen har en edge i framtiden, iaf tills AIn ersätter oss helt. Men existerande C++ kodbaser kommer som sagt inte försvinna, och även mängden C++ utvecklare minskar snabbt vilket gör att det inte direkt är något hot mot folk som bara vill jobba med C++.

Vi har absolut sett problem att hitta kompetent C++ folk, och att erbjuda folk att kunna delvis jobba i Rust har gjort att vi lockat en del heta kandidater som är hungriga på att skriva Rust professionellt.

Du menar alltså att 3 av 7 företag i MAG7 byter p.g.a. kompetens-brist? Har dom inte ringt dig då?

Du blandar helt klart ihop "concurrency" med "parallellism". Notera att "concurrency" inte kräver parallellism, men en trevlig bieffekt är ofta att man får viss parallellism när man utnyttjar "concurrency" i många ramverk.

Även om man kör på en enda fysisk CPU-kärna så krävs ju synkroniseringsprimitiver om "concurrency" realiseras via m.h.a. OS-trådar (vilket innan coroutines var rätt vanligt i C++).

Men "concurrency" kan absolut vara enkeltrådat också. NodeJS och därmed också Electron-appar är i grunden helt enkeltrådade, även om det finns sätt runt det hela.

C# är idag dels hyfsat vanligt för att utveckla spel. Sen kanske du hört talas om applikationer som Visual Studio och MS Office? Även om stora delar fortfarande är skrivna C++ är väldigt mycket av UI-logiken idag C#/WPF.

Microsofts första UI-ramverk för C# var Windows Forms. Ett ramverk man försökt dödat under väldigt lång tid utan att lyckas då helt enkelt allt för många fortfarande använder det. C#/Winforms var och C#/WPF är rätt mycket standardmetoden för att skriva desktop-applikationer i Windows sedan länge. Men trenden går helt klart mot Electron och än mer mot webblösningar, så det går "sådär" med de försök MS gjort med att ersätta WPF (WinUI3 är "det senaste", men det verkar ha relativt lite resurser från MS...).

MFC var rätt stort. Vet inte hur bra det går att söka bakåt, men det fanns ju väldigt mycket böcker och andra resurser om MFC på 90-talet. En kritik ramverket dock fick var att Microsoft inte "ate their own dogfood". Utanför Visual Studio var det väldigt få produkter från Microsoft som använder MFC och det var tyvärr en hel del buggar i MFC (använde det själv hos två olika arbetsgivare i slutet på 90-talet).

Den liknelsen fungerar bara om man ser F1-bil som något hyfsat vanligt. Rust är rätt mycket också en F1-bil i så fall, med den liknelsen en lite nyare modell där man kan åka lika snabbt / snabbare med bättre säkerhet.

Även om Javas "JIT kan ge bättre prestanda än native-språk" länge var "i teorin, men inte i praktiken" är det något man faktiskt lyckades få till. Idag kan JVM-baserade språk prestera på absolut topp-nivå inom många områden, du har fått konkreta exempel i tråden där en GC faktiskt kan ge bättre prestanda jämfört med logiskt motsvarande C, C++ eller Rust-kod.

Finns också optimeringar man kan göra relaterat till lock-free/wait-free algoritmer som endera kräver att minne är typ-konstant (en viss minnesadress representerar samma typ genom hela programmet) alt. man har access till en GC. I din liknelse är väl det kanske formula-e då för JVM-språken, d.v.s. sämre på vissa saker och bättre på andra.

Herregud.

Vi har nästan en miljon rader C++ kod i produktion, deployat både på AWS men även hundratusentals bilar kör vår mjukvara.

Vi tar det igen. Jag säger inte att C++ kommer försvinna.

Men när vi tittar på hur snabbt och säkert, utan buggar och kraschar olika team kan producera kod, då ligger Rust mjukvaran före i vår organisation. Att säga att att "du behöver bara undvika att skriva buggig kod" funkar inte i verkligheten.

Som företag kan man antingen ta in sån statistik (finns liknande historier bland stora FAANGS som redan länkats i tråden) eller så kan man stoppa huvudet i sanden och fortsätta med C++ till nyutveckling också.

Om man har personal som enbart kan C++ och inte vill lära sig nytt, och er domän och mjukvara inte ändrar sig speciellt fort, ja då kanske det valet att stanna på C++ funkar ett tag till. Vad vet jag.

Ja, andelen problem där du behöver systemspråk som C++/Rust är otroligt få i relation till all mjukvara. I sverige är ju Ericsson och Volvo enorma arbetsgivare där C++ används till stor del pga embedded vilket ger en något skev bild av hur stort C++ är jämfört med en mer internationell vy.

Jag skulle säga att Rust är större i USA än i Sverige, även om det finns många bolag som inte syns mycket i Sverige som använder Rust.

Snabb sökning begränsad till Stockholm ger 50+ jobb taggade med "Rust". Så om man absolut vill jobba med ett specifikt språk går det nog att fixa, i alla fall om det inte är allt för exotiskt språk och man befinner sig i närheten av någon lite större stad.

Det är extremt lätt att bli "hemmablind" och att dra allt för stora växlar på vad man ser i sitt eget närområde. Har jobbat relativt lite med Rust på arbetstid, men har ändå jobbat med Rust-projekt på två olika företag.

Ska man gå på "vad företag söker" gissar jag Python, Java, C# och JS är rätt dominerade idag...

"parallellism" och "concurrency" är två rätt olika saker som väldigt ofta blandas ihop.

Det du beskriver som önskvärt på servers är "concurrency", vilket är rätt naturligt.

Det finns absolut potentiella säkerhetsproblem, vissa orsakade av felaktig synkronisering mellan OS-trådar (well, om man inte råkar använda safe Rust där sådant upptäcks av kompilatorn). Finns självklart också problematik relaterat till prestanda, om man vill förbättra detta med olika former av cache så blir det så klart också synkroniseringsproblematik.

Det vi diskuterade längre upp är om C++ eller Rust är enklast/mest effektiv om man vill optimera för parallellism, d.v.s. huvudmålet är att så effektivt som möjligt optimera ett "compute-bound" problem. Här är min rätt bestämda åsikt att Rust idag har ett övertag mot C++ både i prestanda och säkerhet (race-conditions kompilerar inte i Rust, de ger buggar som kan vara skitsvåra att hitta i C++).

Men det du beskriver är som sagt "concurrency". Min åsikt är att Rust inte är fullt lika stark där, även om stödet finns i form av Tokio. C++ har historiskt inte varit stark här heller, ASIO är knappast roligt och även om det absolut går att göra detta väldigt effektivt i C++ (något t.ex. NodeJS är ett exempel på) så är det allt annat än enkelt eller elegant. Nu finns ändå coroutines vilket potentiellt kan förbättra denna punkt framåt. Men tror ändå inte vare sig C++ eller Rust kommer matcha Go på denna punkt.

Just då man ofta, men långt ifrån alltid, kan dra nytta av flera kärnor när man optimerar för concurrency är orsaken varför dessa koncept ofta blandas ihop.

I både Rust och C# blir nog distinktionen mer tydlig. I Rust är Rayon och i C# är t.ex. TPL bra verktyg för att hantera "parallellism". Det är nog sällan man tar till dessa i fallet du beskriver ovan.

Istället skulle man använda async/await i båda fallen. Huvudmålet är inte att maximera användning av CPU-kärnor, tvärtom är det positivt och rätt gjort ett av utfallen av bra "concurrency design" att man kan hantera väldigt många samtida användare per kärna.

I C/C++ var det tidigare ännu lättare att blanda ihop dessa två koncept då båda byggde på OS-trådar, som i sin tur tyvärr har en dålig abstraktion där dessa två koncept blandas ihop. Idag är det mer renodlat: coroutines för "concurrency" och parallell execution policy för "parallellism". I den server som fullt ut nyttjar C++23 skulle man långt mer använda coroutines, parallell execution policies är något man eventuellt kan nytta i något specialfall där.

Fast oavsett: när det kommer till det klart svåraste, att skapa kod som är fritt från data-race (något som kan ge alla möjliga typer av buggar, inklusive säkerhetshål), så har Rust egenskapen att kunna garantera att programmet är data-race free och samtidigt också ge motsvarande effektivitet som C++. Det är en jättefördel!

| D:\dev\investigate\limbo\core                         | schema.rs         |  1615 |  1313 |   27781 |  149 |  236 |
| D:\dev\investigate\limbo\core                         | types.rs          |  1673 |  1387 |   32677 |  123 |   59 |
| D:\dev\investigate\limbo\core\functions               | datetime.rs       |  1696 |  1440 |   33182 |  155 |  376 |
| D:\dev\investigate\limbo\core\storage                 | sqlite3_ondisk.rs |  1752 |  1389 |   36108 |  193 |   41 |
| D:\dev\investigate\limbo\core                         | util.rs           |  1984 |  1740 |   39846 |  102 |  418 |
| D:\dev\investigate\limbo\core\translate               | expr.rs           |  2616 |  2423 |   44231 |  112 |   72 |
| D:\dev\investigate\limbo\core\json                    | jsonb.rs          |  3992 |  2822 |   65700 |  355 |  526 |
| D:\dev\investigate\limbo\core\vdbe                    | execute.rs        |  7084 |  6498 |  145416 |  110 |  536 |
| D:\dev\investigate\limbo\core\storage                 | btree.rs          |  7339 |  5987 |  138357 |  742 |  298 |
| Total:                                                |                   | 62289 | 50911 | 1102657 | 4617 | 6364 |
+-------------------------------------------------------+-------------------+-------+-------+---------+------+------+

Veckans orelaterade gnäll?

Det har merge:ats patch sets varje dag denna månaden så jag vet inte riktigt vad du syftar på...

Snabbkoll i git-historiken(patchar mot master denna månaden):

180 files changed, 14118 insertions(+), 6437 deletions(-)

Nu har jag inte benkoll på hur `git diff --stat` fungerar men har tagit mellan första commiten för månaden och HEAD så det borde finnas ännu mer arbete som pågår på diverse brancher som inte merge:ats ännu.

What are you, the code police?

Alltså, vad är din poäng? Du väljer ut random GitHub Repo och...vad?

Gubbgnäll har ju en egen tråd, men det tror jag du vet.

Linux lär i NodeJS hänga i en epoll() längst ned. Det är ett väldigt effektivt sätt att hantera många samtida händelse. När någon blir klar aktiveras associerad promise (eller callback, men det är väl rätt old-school?) och man kör den logiken. Det är typexempel på concurrency.

I Windows kanske man hänger i en message pump, skulle i alla fall fungera rent logiskt men är inte lika effektivt som epoll() och den mer direkta motsvarigheter i Windows är I/O-completion ports.

Går att ha flera Windows messages pumps i samma applikation. Går att ha en per tråd om man behöver. COM STA (Single Threaded Apartment) använder Windows message pump som del i sin IPC-marshaling. Det är också exempel på concurrency (STA var/är rätt vanligt då VB/VBA inte stödjer MTA).

#include <algorithm>
#include <chrono>
#include <coroutine>
#include <execution>
#include <iostream>
#include <numeric>
#include <thread>
#include <vector>

// This would be some I/O-bound operation in a real application
struct SleepAwaitable {
    std::chrono::milliseconds duration;
    bool await_ready() const noexcept { return false; }
    void await_suspend(std::coroutine_handle<> h) const {
        std::thread([h, d = duration]() {
            std::this_thread::sleep_for(d);
            h.resume();
        }).detach();
    }
    void await_resume() const noexcept {}
};

struct Task {
    struct promise_type {
        Task get_return_object() { return {}; }
        std::suspend_never initial_suspend() noexcept { return {}; }
        std::suspend_never final_suspend() noexcept { return {}; }
        void return_void() noexcept {}
        void unhandled_exception() { std::terminate(); }
    };
};

Task hello_coroutine(int i) {
    co_await SleepAwaitable{std::chrono::milliseconds(10 * i)};
    std::cout << "[C" << std::dec << i << "]Hello from thread " << std::hex << std::this_thread::get_id() << "\n";
}

void hello_par(int i) {
    std::vector<int> indices(i);
    std::iota(indices.begin(), indices.end(), 0);
    // Run in parallel
    std::for_each(std::execution::par, indices.begin(), indices.end(), [](int idx) {
        // This would be some compute bound operation in a real application
        std::this_thread::sleep_for(std::chrono::milliseconds(10 * idx));
        std::cout << "[P" << std::dec << idx << "]Hello from thread " << std::hex << std::this_thread::get_id() << "\n";
    });
}

int main() {
    int i = 0;
    for (; i < 10; i++) {
        // Run concurrently, _may_ be on a single thread or on multiple threads
        hello_coroutine(i);
    }
    hello_par(i);
    std::this_thread::sleep_for(std::chrono::milliseconds(300));
    return 0;
}

En notering: vilken shit show det var att använda något efter C++17, specifikt std::print, coroutines samt parallel execution policy...

std::print fungerar inte på Linux med GCC, specifikt fungerar det inte med GNU libstdc++. libc++ (Clang, standard på MacOS) stödjer dock detta.

parallel execution policy är däremot inte implementerad av Clang/libc++... På MacOS gick det inte heller att enkelt få det att fungera med g++ (men ett helt annat fel än med Clang).

På Linux "fungerar" det rakt av, fast inget körs parallellt... Det är helt enligt standard då det bara är en hint. Länkar man med Intel Thread building block så blir det helt plötsligt också parallellt.

coroutines fungerade rakt av både på GCC/Clang och på Linux/MacOS. Men tydligen behövs det där lite handpåläggning om man kör med Windows/MSVC (enligt ChatGPT).

Bortsett från problemen med minnessäker kod känns det som allt bortom C++17 i praktiken är rätt oanvändbart om man vill ha något form av stabilt stöd på mer än en enda plattform. Hur har det blivit SÅ dåligt (har inte använt C++ jättemycket efter C++17, dock använt C++11/14/17 massor då jag bl.a. varit med och implementerat standardbiblioteket för ett OS till PowerPC, 32-bit Arm, ARM64 och x86/x86_64).