20-talets högsta prioritet på språk - Säkerhet & Snabbhet

Redan nämnt i tråden, men du kanske missade det: Rust-gänget har faktiskt tänkt ett steg längre än de flesta andra just kring stabilitet. Finns något som kallas "Editions", dessa släpps rätt sällan (finns idag 3 st, 2015, 2018 och 2021) och kör man t.ex. Edition 2015 är den garanterad att vara helt kompatibel. Varje enskild "crate" (tänk bibliotek i C/C++) måste använda samma "edition", men en applikation kan använda sig av "crates" som var och en kör olika "editions".

Angående användningen

Världens största kommersiella RTOS, VxWorks, har stöd för Rust out-of-the-box.
Infineon, Tysklads största tillverkare av halvledare, har Rust stöd för deras mikrokontrollers.
AVR har rätt bra stöd för Rust, AVR-baserade mikrokontrollers är kanske mest kända av gemene man i kontext av Arduino men de är billiga och populära kretsar för custom-designer.
ESP8266/ESP32 + FreeRTOS + Rust finns också.

Linux/Windows har numera officiellt stöd för Rust i kärnan. Linux är utanför mikrokontrollers/OS-lösa system idag världens största embedded OS, det har definitivt Rust stöd.

Däremot ska man vara medveten om att no_std varianten av Rust inte nått samma mognad som "normalversionen" av språket. Med no_std går det redan idag att använda Rust ihop med de flesta aktuella mikrokontrollers och OS-lösa system.

Men gör man nischade saker är det självklart ett problem att nivån på vissa bibliotek kan ha tveksam kvalité. Just det var något som fick mig att gå från Rust till Go i ett projekt, visade sig att Go har betydligt mognare bibliotek för RS485/ModBus än Rust (efter att använt det skulle jag säga att Go biblioteket även slår de C bibliotek jag testat på fingrarna i funktion och stabilitet!).

På samma sätt som med kod skriven i alla andra språk - skickliga programmerare som vet vad de håller på med, och rejält med testning utförd av duktiga testare.

Det finns inget programmeringsspråk eller kompilator som kan upptäcka eller förhindra alla fel som programmerare kan ställa till med.
I en del programmeringsspråk (som till exempel C++) så är det dock väldigt enkelt att skriva dålig kod, vilket gör att kod skriven av medelmåttiga programmerare i sådana språk ofta är dålig. (Dålig kod inkluderar felaktig kod, men även kod som är svår att läsa eller förstå och kod som är svår att modifiera i efterhand)
Andra programmeringsspråk (som till exempel Rust) gör det lite svårare att skriva dålig kod vilket i sig minskar förekomsten av fel.

Vad är problemet?

Är väl bara göra något likt detta och sen slänga in den kod du vill jämföra.

Sen är ju frågan om "minst" assembler kod alltid är bäst...

I vissa lägen kommer Rust generera mer för den helt enkelt kollar fler saker runtime. Sen kan det bli rätt mycket mer assembler om kompilatorn t.ex. försöker sig på SIMD-optimeringar (händer ibland vid -O3 i alla fall), mer kod men typiskt snabbare.

Så är långt ifrån lätt att göra något supervettig med en sådan jämförelse.

Kan du utveckla varför? Har ingen koll på assemblerkod så är nyfiken på detta.

Det är väl bättre med 20 byte kod än 10 byte kod om 20 byte är klart snabbare? (T ex Loop unrolling)
Om du inte försöker kompilera för antika datorer med några MB RAM eller dylikt.

Kan vara endera beroende på typen av fel. Oavsett vilket så måste delar av en kompilators jobb göras för att kunna hitta något som helst problem i kod, men en text-editor eller IDE kan göra vissa enkla kontroller, och i fallet med en IDE så kan den tolka kompilatorns felmeddelanden så att man kan gå direkt till rätt plats i koden.
Just för att upptäcka saknad initialisering av en variabel så är det nästan säkert kompilatorn som varnar - en IDE gör ytterst sällan så pass avancerad analys av koden.

Mindre assemblerkod är inte alltid bättre. I en del fall så kan något mer komplicerad assemblerkod generera snabbare kod än kortast möjliga assemblerkod - men det är nästan alltid högst arkitekturberoende.

Jag skulle säga att det är helt fel. Den enklaste och kortaste algoritmen för att lösa ett problem är mycket sällan den mest effektiva.

För att ta ett trivialt exempel så är en selection sort en av de absolut enklaste sorteringsmetoderna, men den är ineffektiv.
Mergesort kräver mer avancerad kod, men i nästan alla fall så är den betydligt snabbare - O(n log n) kontra O(n^2) för selection sort.

Däremot stämmer det att man inte skall krångla till saker i onödan. I första hand skall man skriva kod som tydligt uttrycker det man vill göra, och först i efterhand skriva en mer avancerad och mer optimerad variant om det visar sig behövas.

I en IDE (Integrated Development Environment) så ingår det ju både kompilator och editor och länkare (och oftast debugger) som samverkar. Exakt vilken komponent som varnar är sak samma vilket är lite av poängen med att ha en IDE jämfört med helt fristående verktyg.

Om den kan upptäcka att minne inte frigörs så är det för att den kör programmet i någon form av debugmiljö där den precis innan programmet avslutas kan kontrollera om det finns något allokerat minne som inte frigjorts.

Om du ofta råkar ut för att överindexera arrayer så skriver du antagligen din kod på något olämpligt sätt. Det finns troligen bättre sätt att skriva din kod på så att du minskar risken för överindexering.

Om du skriver sådan kod för att du tycker det är roligt eller för att lära dig så är det ju en sak, men annars så finns det ju väletablerade bibliotek med funktioner för sådana problem som antagligen är både snabbare och robustare än din kod, och som du kanske borde fundera på att använda.

Arbetar du med små matriser så är det ju möjligt att det extra arbetet dessa bibliotek utför inte lönar sig. Är det bara millisekunder vi pratar om så är det antagligen bara små matriser involverade.
Skulle du börja jobba med stora matriser så misstänker jag att du kommer att se andra resultat.