Microsoft is Rust:ing

För det första så har folk fortfarande inte lyckats skapa robotar som har känslor - bara robotar som kan låtsas ha det.

Som jag sade tidigare - om du nu tror att det är så enkelt, varför gör du det inte själv? Försök gärna - om inte annat kommer du nog att lära dig en del om hur kompilatorer fungerar.

Det är nog specifikt "är det inte bara" som väcker den känslan:

Det är ju inte enbart en nyfiken fråga när någon informerat dig om att det inte är så lätt att validera och du svarar med att "klart det border vara enkelt?". Om detta är stora problem med språken och exempelvis C har funnits i över 50 år och antagligen används av 100 000-tals utvecklare, varför är det inte åtgärdat problemen om det nu är så enkelt?

Nej det är inte snabbare än C och det är väl på ungefär samma hastighet som C++ men alla sådana här mätningar ska man ta med en nypa salt eftersom de oftast inte kan appliceras på ditt use-case.

Om du vill framtidssäkra dig så är det bästa att välja en portfolio med språk som löser olika typer av problem olika lätt. Språk är enbart en liten del det viktigaste är att ha en förmåga att anpassa sig.

Nej, det gör du inte. Ditt första inlägg är kritiserande och inte utforskande. Utöver detta när folk bemöter din kritik så kommer du med omogna inlägg som:

Där du kommer med påstående som ingen gjort om att Rust skulle lösa alla problem. Detta är än en gång ett bevis på att det inte är en utforskande mentalitet.

Jag tror det är här skon klämmer. Du har läst rubriker om att X skulle vara en C- eller C++-killer. Jag skriver både C och Rust och jag gillar båda språken och jag anser _inte_ att stora etablerade projekt ska skrivas om från exempelvis C.

Zig är ett alternativ till C och Rust. Du kan transpilera(transpiler/transcompiler) C-kod till Zig och vise versa. Carbon är introducerad som alternativ till C++ och erbjuder inline-stöd för C++ dvs den har inget med Rust att göra.

Förutom att Valgrind (och liknande lösningar såsom PurifyPlus) inte ser alla fel så är det dessutom ett verktyg som körs under runtime, så det är inget du kan använda när du skriver din kod. Du måste även se till att provocera fram felindexeringen eller hoppsa att den alltid sker, annars säger inte Valgrind något.

Det är klart att ifall du skapar ett jätteförenklat exempel med hårdkodade index så borde en smart kompilator kunna varna dig för det. Men det är ju inte sådana småfel som erfarna utvecklare fastnar i timtal på utan det är ju just när indexeringen/storleken är dynamisk.

Du kan inte stoppa felindexering med hjälp av en smart IDE. Som flera skrivit tidigare så finns det inte tillräcklig information för att avgöra det.

Förutom alla andra missförstånd, felslut och bakvända resonemang* du ger uttryck för som redan pekats ut gång på gång av andra verkar du helt ha missförstått vad en IDE är.

• En IDE är inte ett orakel. Den förkrossande majoriteten av all information du får i en typisk IDE kommer från kompilatorn. I den mån en IDE (eller ett tillägg till den) tillhandahåller mer information än kompilatorn gör den det i regel heuristiskt.

• En IDE är inte auktoritativ. Andra utvecklare i samma projekt sitter i allmänhet med en helt annan miljö, och du kan i praktiken inte ens dra nytta av en IDE i CI. Det enda som faktiskt räknas är vad kompilatorn säger.

* Det genomgående temat i dina inlägg i tråden låter ungefär så här:

1. Du: "[C och C++] är bökigt och omständigt och jag måste ha kontroll på allt. Minsta lilla fel på indexeringen och ALLT blir fel. Det kan ta timmar att felsöka då jag får inget fel om jag överindexerar. […] Helst vill jag få förvarning [om null pointer exceptions] innan jag ens debuggar koden. […] Jag har mycket problem med överindexering hos C […]. Så det tar tid för mig att faktiskt programmera. Jag har stort behov av någon som kan ge mig en varning på […]. […] Att ha en gnällig kompilator skulle jag vilja ha när jag programmerar C."

2. Andra: "Rust löser de problemen du har."

3. Du: "Jag har aldrig kört Rust, bara C och C++. […] Personligen är jag lite skeptisk till Rust. […] Språket attraherar folk som ofta kommer från webbutvecklingssidan(vad jag har sett). […] Jag ogillar att man använder massa tecken. […] Jag märker ingen skillnad mellan Python och MATLAB [så prestandaskillnaden mellan Rust och C är alltså jätteviktig för mig]. […] Nej, det är inte skoj med flera språkalternativ - Det är religion. […] Borde inte [egenskaper som går tvärtemot allt som C står för] vara enkelt fixat hos dom som utvecklar C? Jag menar, dom behöver ju inte röra bakåtkompatibiliteten? Det är väll bara lägga till en funktion som granskar koden när man kör den?"

Som tidigare nämnt: om du har tid och möjlighet att skriva en kompilator – eller bara en typcheckare – för ett litet, påhittat leksaksspråk, kan jag varmt rekommendera det. Det är extremt lärorikt och ögonöppnande! När du har lärt dig grunderna kan du göra ett försök att utöka GCC eller Clang med statiska garantier motsvarande Rusts. Lyckas du kommer du göra miljoner utvecklare världen över evigt tacksamma.

Nej, det är väldigt uppenbart att du inte har kunskap på området.

Nej, det är inte möjligt i alla andra språk, och jo, man kan behöva röra språkets struktur för att kompilatorn skall kunna upptäcka vissa typer av fel.

Valgrind kan upptäcka vissa fall av överindexering, men inte alla, och den gör detta genom att lägga in extra kontroller runt de flesta minnesåtkomster vilket tenderar att göra program betydligt långsammare. Den typen av kontroll kan inte göras av en kompilator, utan bara genom att köra koden med instrumentering.

Låt oss titta på ett mycket enkelt litet C program:

#include <stdio.h>

int main()
{
    int arr[10];
    int a;
    printf("Enter a number:");
    scanf("%d", &a);
    arr[a] = a;
    printf("%d\n", a);

    return 0;
}

Kommer det här programmet att göra en inkorrekt minnesaccess när det körs?
Det kan varken du eller någon kompilator svara på eftersom det beror på vad man ger den för indata, men vad som kan sägas om koden är att den är osäker då den använder indata utan att kontrollera att den har tillåtna värden.

Rust löser inte heller problemet med felaktiga index. Det den gör är att den tar bort odefinierat beteende, och säger typ "om man indexerar 'utanför' arrayen SKA programmet avslutas med ett felmeddelande". Ungefär som Java, C#, Python osv (som dock alltid kastar exceptions i det fallet). Skillnaden mot t ex Java är väl dels att man kan garantera att ett program i Rust är väldefinierat även när det är flera trådar inblandade, och dels att man inte har någon garbage collection.

Det skulle vara "ganska lätt" (eller iaf fullt genomförbart) att göra (singeltrådad) C++ lika väldefinierat som Rust just vad gäller indexering genom att låta kompilatorn generera kod som alltid håller ordning på pekare. Men C++ har en viktig princip att aldrig tvinga på programmeraren någonting som kostar prestanda (förutom möjligtvis exceptions, men i praktiken har ju kompilatorer ofta möjlighet att kompilera utan stöd för det). Vill man ha det finns det gott om andra språk att använda istället.

Något liknande med use-after-free eller double-free, det skulle vara "ganska lätt" att detektera det här vid körning i C++ på bekostnad av prestanda. Men i Rust och t ex Java, C#, Python är det omöjligt att göra de felen. I Rust för att språket är byggt från grunden för att hålla koll på livslängder av objekt, vilket kan göra det väldigt frustrerande att använda men möjliggör för kompilatorn att verifiera redan vid kompileringen. I de andra språken för att man använder garbage collection istället för free. I C++ är det omöjligt i det generella fallet.

Då kan man fråga sig VARFÖR det är omöjligt? Kan inte någon smart person komma på något sätt? Och svaret är NEJ. Det finns teoretiska begränsningar för analys av program. Man kan t ex inte konstruera en kompilator (eller IDE-plugin eller whatever) som tar reda på om ett godtyckligt program kommer avslutas eller inte, vilket är det berömda halting problem (https://en.wikipedia.org/wiki/Halting_problem ). En generalisering av det är Rices sats (https://en.wikipedia.org/wiki/Rice%27s_theorem ) som säger "all non-trivial semantic properties of programs are undecidable", och här hamnar antagligen double-free, use-after-free, array-index-out-of-bounds etc.

Det är nog åtskilliga här på forumet som har skrivit en kompilator - inklusive undertecknad. Det är en ganska vanlig uppgift på universitetsutbildningar i datavetenskap. Oftast bara små, enkla kompilatorer, men ändå kompilatorer.

Jag antar att det där är i C eller C++.
Det där fungerar alldeles utmärkt oavsett vilka tal som är involverade. Man skall ju känna till att aritmetiken utförs modulo 2^16 så att man inte förväntar sig något annat, men det är väldefinierat i språken att så skall göras, så det bör man kunna räkna med att programmerare vet - annars får de läsa på bättre.

Programmeringsspråk är inte strikt ordnade från "bäst" till "sämst". Detta (och motsvarande för ramverk etc) har du fått förklarat för dig i tråd efter tråd genom åren, men det verkar inte hjälpa.

Nej, om det bara var det du gjorde, och förmedlade, skulle ingen ha några invändningar.

Men ja, ditt sätt att argumentera kan stundtals vara provocerande, även om det inte är din avsikt. Det är som att du inte alls tar till dig vad någon skriver. Att dessutom konstatera att "det är religion" och därför "inte skoj" med fler alternativ framstår minst sagt som märkligt, med tanke på hur du själv i åratal torgfört synnerligen dogmatiska åsikter om programmeringsspråk här i forumet.

Men jag måste också säga att jag även förnimmer den där sidan av dig som faktiskt vill undersöka olika aspekter, vrida och vända på saker och skapa bra mjukvara. Det är förbryllande.

Du efterfrågar lösningen på ett problem som är ekvivalent med haltproblemet.

Valgrind är ett verktyg för dynamisk analys, som @Erik_T, @orp och framförallt @Curik redan förklarat. Det är helt ojämförbart med en statisk typcheckare.

Du vet att man får bygga kompilatorer redan på universitetet va? Jag har skrivit flera stycken även efteråt.

Man "skickar" inte något till en uint16_t. Och att det fungerar så länge du inte skriver ett tal större än vad datatypen stöder är ju.... rätt grundläggande kunskaper.

Sorry men det låter kanske som att du borde ta ett steg tillbaka och låta andra som har mer erfarenhet och kunskap få svara på dina frågor istället för att göra dessa svepande och breda påståenden.