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

Misstaget de håller på att göra i linux nu (givetvis min personliga tolkning) är att inte förstå att människor är olika och tänker olika.

Varför tycker vissa att C är lätt medan andra tycker C är jättesvårt?
Varför har vissa lätt för att lära sig nya länders språk (svenska, tyska, engelska mm), medan andra har svårt för det
Varför kan vissa lära sig rita/måla medan andra knappt kan rita en streckgubbe.

Ta alla som har gått lång utbildning, kanske avancerade kurser på högskolan. Duktiga. Nästan alla där är notoriskt dåliga programmerare. Medan anda kufar som knappt kan stava ändå är mycket skickliga programmerare.

C programmerare är speciella, det är samma med C++ men där är det inte lika extremt.
När en C programmerare läser kod så är det inte koden i sig som är det viktiga, vad kodaren egentligen gör när den läser är att måla upp en bild över datat. Hur data lagras i minnet och hur data transporteras. Koden är bara en slags teknik för att transportera/omvandla data mellan olika delar områden i minnet. Det här är en speciell talang.
Kod som skrivs följer en del regler som gäller för hur datorer arbetar med data, C programmerare vet om hur en processor fungerar och tänker hela tiden utifrån det perspektivet.
För att klara det här effektivt är pekare helt centrala, det är mycket svårare att hantera sådan kod på ett smidigt sätt utan att arbeta med adresser.

De programmerare som INTE fokuserar på data utan istället programmerar utifrån hur människor tänker, försöker beskriva saker med litterära namn istället för datoranpassade. De kommer ha mycket svårt att förstå C koden, de läser C kod på fel sätt.

Det här tror jag kommer göra att Rust och C inte kan jobba ihop, problemet är generellt så det gäller absolut inte bara Rust. Exempelvis är det mer eller mindre omöjligt för C programmerare att diskutera lösningar med Java programmerare. De tänker alldeles för olika.
Som om en författare skall diskutera med en snickare. Två helt olika områden.

C programmerare kan ofta hantera enorma mängder kod, men det har inte något att göra med att de kommer ihåg koden utan att de har en ritning i skallen över hur datat i applikationen/systemet ser ut. De utgår från denna bilden/ritningen.

Rust programmerare gör det inte, de flesta andra programmerare gör det inte heller. Det är inte en kunskap som premieras i skolan, skolan premierar lässkicklighet och förmåga att minnas vad man läst.

Eftersom det är så olikt sätt att bearbeta kod blir det ständiga konflikter.

Val av språk, varför vissa gillar C medan andra hatar det. Man kan ganska snabbt se hur programmerare tänker baserat på hur de skriver kod och vad för typ av lösningar som de gillar.
Det finns säkert utvecklare som tänker som C programmerare i andra språk men de kommer inte trivas med språket de använder.

Har du lärt dig C för att det är ett sätt att komma in på arbetsmarknaden eller gillar du språket?

Tre frågor:
- Varför hobbykodar du i Rust?
- Vad tycker du om kodstilen hungarian notation?
- Tycker du det är svårt med pekare, om du inte tycker det saknar du isåfall inte att leka med minnet som du kan göra i C men som inte går i Rust

Eller så lär du dig ett multiparadigm språk som exempelvis C++ och kan sedan allt. Resten är bara olika syntaxer kombinerat med medföljande bibliotek.
Det är en av skillnaderna med att lära sig förstå minne och CPU jämfört med att lära sig programmeringsspråk.

En dator kan bara ett enda språk och det är processorns maskinkod. Allt omvandlas till det.

Jämför med att lära dig multiplikationstabellen.
- Teknik 1: Lär dig alla kombinationer utantill hur man multiplicerar ihop tal från 0 - 9 och applicera regler på det.
- Teknik 2: Lär dig hur multiplikation fungerar, att 2 * 2 innebär att man plussar ena talet det antal gånger som det andra talet säger.

Med teknik 1 finns det gränser med vad som går att åstadkomma eftersom man inte förstår logiken. En hjärna kan bara komma ihåg så mycket.

Vad är det jag missar om jag lär mig C++?

Det här är C++ kod

   std::string stringDbName = GetApplicationFolder();
   stringDbName += "db.sqlite";
   gd::database::database_i* pdatabase = (gd::database::database_i*)new gd::database::sqlite::database_i("db");
   auto result_ = pdatabase->open({ {"file", stringDbName} }); 

   gd::database::cursor_i* pcursor = nullptr;
   pdatabase->get_cursor(&pcursor);

   result_ = pcursor->open("SELECT * FROM TCustomer;");
   gd::table::dto::table tableCustomer;
   gd::database::to_table(pcursor, &tableCustomer);
   std::string stringResult;
   gd::table::to_string(tableCustomer, stringResult, gd::table::tag_io_header{}, gd::table::tag_io_csv{});
   std::cout << stringResult << "\n";

Logiken under där är gjord så att samma kod fungerar på alla större databaser (SQL Server, Oracle, postgresql, mariadb o.s.v), även sqlite som i exemplet.
Det är C++ kod som abstraherat logiken för att med nästan ingen kod klara av att göra lite vad som helst med databaser.

När du skriver "Erlang/Elixir och 2% i Rust/C?" och att du väljer dessa språk så beror det inte på språken utan att det följer med färdigskriven kod du kan använda dig av.
Det kan du göra i C++ med, du kan abstrahera logik som inget annat språk klarar av med samma effektivitet.

Nej det är inte unikt jag menar utan med samma effektivitet (alla vet väl att man abstraherar logik i alla språk)

Det är en helt annan diskussion. Självklart får varje utvecklare välja de verktyg utvecklaren behärskar

Tråden handlar om minne och minnessäkerhet, att C/C++ får kritik där. En kritik som inte är korrekt och det är kanske därför som amerikanska staten backat ordentligt

Myndigheter är stora inköpare av system skrivna i C# vad jag vet. Men försök hitta jobb som C# programmerare idag, där går AI fram som en ångvält.
Tror inte valet baserats på minnessäkerhet utan att det har gått att få tag i utvecklare som går att byta ut.

Jag tror att du är rätt ute här.

Själv jobbar jag med säkerhetskritisk programvara på ett medelstort bolag som har drygt tusen utvecklare. Det mesta av vår gamla projekt är skrivna i C (μC) eller C++. Redan nu startas det upp Rust-projekt hos oss, men enligt de som är ansvariga för det extremt komplexa ämnet "certifieringar och funktionssäkerhet" (tänk: risk för personskador vid malfunction) finns inte verktygen som behövs för att stödja "process-aspekten" där än. Därför används framför allt Rust just nu (lite paradoxalt) just för de projekt som har LÄGRE säkerhetskrav. När ekosystemet kring Rust har mognat till något steg till så tror jag att vi kommer få se en explosionsartad tillväxt för språket inom bl.a. flyg, rymd, medtech, automotive, railway, robotics, och allt möjligt där funktionssäkerhet och realtidskrav är viktigare än allt annat.

Dessa företag (kan gissa vilka) har egentligen behov av en egen kompilator/toolchain men kan inte och vill inte slösa resurser på det. Att köpa in är ofta för dyrt i längden och man vill inte bli inlåst mot en levrantör av något. Största problemet med cerifiering är att man blir helt beroende av en version av en kompilator. Att stega en sådan är inte helt enkelt ur ett manstimmar perspektiv. Men vist, inte helt kul att ligga på gcc 4.x. 5.x. osv. Kan också vara så, med stor sannolikhet, att de saker man redan köpt in inte stöder det senaste eller ens en LTS version.

Problemet med Rust är lite som med c++ med alla fancy standard bibliotek och funktioner, det är för lätt att göra saker som man inte förstår den totala effekten av. Kul om en kille sitter med Rust när man har 20 utvecklare som inte hört talas om det eller har tid att sätta sig in i det. Då har man klantat sig i management. Teamwork! Please.

Säkra system -> håll det enkelt. Ofta enkla saker som ska göras ändå här annars är något feltänkt i sin system arkitektur från början. Till mer beslutsfatande delar i system, go wild... inom visa gränser för vad man klarar av att system verifiera - att ha riktig hårdvara att köra på (eller hyfsat lik) underlättar ju... inte alla företag som förstår det heller. Man är ändå tvingad att dra in 3:e part libar/frameworks för att få det att fungera. Troligtvids ligger man och kör med Linux som OS (så bara där fösvinner en del aspekter här som relativt omöjligt ändå)

Men en traktor är inte en bil.

Vi kommer från en tid det nästan räckte med att säga "jag är intresserad av att lära mig programmera" och det var nära att man fick jobb. Efterfrågan på programmerare har varit extremt hög. Vet några som fick jobb efter tvåveckors kurs i html.

Eftersom efterfrågan varit så hög har också löner trissats upp (ordentligt).
Nu är det tuffare tider och det fler får lönsamhetsproblem, samtidigt sitter de med överbetalda utvecklare.

Det går absolut att få jobb om du har lång erfarenhet, är beredd att gå in på lägre lön. Är man däremot ny idag är det jättetufft i enklare miljöer.

Vad skulle du sagt om exempelvis staten gick ut och sa till spelbolagen att sluta skriva spel i C++ för att få säkrare kod?

Försöker svara senare men just angående "säkerhet" och mjukvara är detta forumet kanske inte platsen det går att diskutera sådant. Jag personligen har aldrig trott att syftet med reglerna varit att få säkrare kod men det har tagit lite tid och gräva.

Är ganska säker på att de kommer plocka bort regeln om USA vill hänga med i teknikutvecklingen. Annars kommer andra länder ta över.

+1

Det här kommer bita Rust i baken ordentligt. Möjligen har det varit tvunget att skapa en miljö som gör det lätt att komma igång med mindre projekt för locka utvecklare. Men det som fungerar i liten skala fungerar inte lika bra när det växer.

Python har inga ambitioner av att bli ett språk man gör större system med men har det där med att det dräller av komponenter, där är poängen med att snabbt slänga ihop något, behöver de ändra så skriv nytt. Där är det ok med komponenter som plötsligt inte fungerar. De skriver nytt och tanken är inte att skriva kod som går att underhålla.

Python är fantastiskt populärt till det som det är gjort för.

Men jag skulle inte säga att C++ har massa fancy bibliotek. C++ har STL och en del från C tiden, det finns misstag i det men är ganska få och en del har tagits bort.
I C++ är det mer marknaden som får avgöra om de väljer något externt eller utvecklar själva. Jag hade själv önskat att de höll igen lite på hur mycket man väljer att lägga in i STL.

Mina två önskemål nu om språket C++ är
1: Möjligheter att deklarera funktioner på flera ställen. Att man kan "bygga på" en deklaration. Orsaken till det är att kompilatorer blivit så bra och kan hjälpa till mycket samt de bättras på hela tiden. När C++ lägger till saker som mest är för kompilatorn så kladdar det ner läsbarhet. Jag väljer själv att låta bli och deklarera för saker som skulle vara bra att ha just för att koden blir kladdigare. Hade jag kunnat gömma undan det så hade det varit bättre.
2: Kunna sätta prioritet när det blir konflikt på överlagrade metoder, att jag skulle kunna deklarera metoder så när kompilatorn har två eller fler möjligheter att välja metod så har jag deklarerat prioritetsordningen. Det hade underlättat att skriva generell kod

Kan inte tänka mig att C++ gänget eller C gänget känner någon oro. I alla fall inte utvecklare. De som möjligen kan känna oro är de som tjänar pengar på att lära ut, prata eller kanske på annat sätt är involverade med att sprida C++. För dem är det viktigt med fler potentiella kunder.
Så länge jag varit programmerare har det kanske gått 5 VB programmerare på varje C++ programmerare eller senare så 5 C# programmerare på varje C++ utvecklare. Antalet personer som skriver C eller C++ har aldrig varit den stora massan.

Möjligen att det ökat en del senaste 5-10 åren när så mycket skall datoriseras.

Skulle det dyka upp något språk som är en värdig konkurrent skulle nog en majoritet av C/C++ utvecklare byta ganska omgående. Jag tror inte de som använder språket gör det för att de älskar språket utan att det är det språket som är bäst lämpat för det man skall göra.
C++ är mitt huvudspråk men skriver mycket javascript och en del python och LUA också.

Min egen "oro" har snarare handlat om att de senaste 10-15 åren så har utveckling handlat mer och mer om deklarativ kod, mycket på grund av utspädning. Att fokusera på att skriva deklarativ kod är enligt mig ett helt annat yrke men kletas samman med programmering.

Möljligen, men jag tror många undrar vad Linus strategi varit för jag tror inte det blir ett lyckligt slut om han inte kraftigt förklarar att kod inte skall blandas. Att skriva ett operativsystem är hemmaplan för C, inget annat språk är så lämpat för det som C. C och Rust kan inte diskutera, personer i de olika lägren är för olika. Det är min slutsats efter att ha läst olika konverseationer i snart ett halvår. Vissa forum där det finns personer som gillar Rust, där är det nästan omöjligt för C/C++ att beskriva något om språket innan de hugger. Jag vet massor som är riktigt trötta på det. Linkedin har flera som postat om att Rust måste ta och tagga ner.

Hantera minne är mycket kraftfullt verktyg men det går knappt hitta ställen där det inte finns rust som vips är där och skriker ajabaja.

Nej men var på vippen att testa. Mitt huvdsakliga problem med rust är att så många skriver message chains, förkortar variabler och har svårt för hungarian notation. Bara en sådan sak som att sätta "m_" medlemsvariabler är svårt att få gehör för.

Det är också vanligt med formaterare när rust, tror en vanlig som används kallas för rustfmt eller något sådant.
Har jag kommit in i någon grupp där de använder formaterare så är det bland det första jag förösker kasta ut. Formaterare är INTE bra att använda sig av. Programmerare måste lära sig skriva kod, enligt mig är programmering mer en konstart än att det är något man kan läsa sig till.

Angående AI så tror jag att jag är tidig på bollen men det är inte svårt att förstå hur mycket detta kommer förändra. För mig känns det som man fått "superkrafter" men det är inte bara jag utan alla andra med.

Självklart är det många som också använder tekniken fel men tror att de snabbt rensas ut.
Och det är självklart inte bara programmering som påverkas av AI, detta kommer förändra hela samhället.

Det är många "nya" programmerare idag och där är det nästan inga C++ men det har mer och göra med att behovet i andra områden, exempelvis web utveckling mm. Där har det varit efterfrågan. Och standarden på programmerare är mycket lägre idag än förr.
Skrivs C/C++ kod kan den användas länge. Ta världens kändaste databas, sqlite. C kod där det mesta skrevs för många många år sedan. Det finns inte anledning att skriva en ny sqlite. Även om någon skulle kunna göra det på kanske ett halvår så krävs det så mycket tid för att marknadsföra och samtidigt tävla mot en databas som finns överallt.

Jag har jobbat en hel del med att bädda in LUA i C++ kod. Tills för c.a. 3 år sedan fanns en hel hög med wrappers, alltså kod som förenklade arbetet med att koppla lua till C++ kod. Men som kom sol2. Nu använder alla det och den slaktade i princip resten av biblioteken. Det kommer dröja innan någon skriver en ny wrapper till LUA.

C++ är för effektivt, därför kommer det aldrig bli så många som jobbar i det. Omöjligt att tävla mot skickliga C++ utvecklare.

Det finns självklart en hel massa C++ programmerare som borde sitta i andra språk för det är inget för nybörjare. De här kan säkert orsaka ett och annat problem sett till minnet.
Är man van så är det inte ett problem

Det är inte bättre. Enda anledningen till att jag tänkte testa är att andra utvecklare i Rust är så entusiastiska. Samtidigt är koden de skriver inte speciellt bra om det inte handlar om deklarativ kod. Lite som när man ser yngre spelprogrammerare, de är också helt värdelösa i arkitektur och skriver illa. Man vill få fram sitt spel och är inte jätteintresserad av koden som skrivs.
Jag är själv typiskt entusiast programmerare (hobby och yrke). Det skiljer exempelvis gruppen mot C# och Java. De som skriver kod i dessa språk accepterar i princip vad som helst, det är bara ett yrke. Utvecklare i Rust har mycket mer driv.