Vid det senaste Open Source Technology Summi (OSTS) , en senior ingenjör på Intel, sa att hans företag är intresserade av att Rust ska nå "paritet" med C-språket som fortfarande dominerar system och utveckling på låg nivå inom en snar framtid. Under rubriken "Intel and Rust: The Future of Systems Programming" pratade han också om systemprogrammerings historia, hur C blev det förinställda programmeringsspråket för system, vilka egenskaper hos Rust som ger det en fördel framför C, och hur det helt skulle kunna ersätt C i detta programmeringsområde.
Systemprogrammering är utveckling och hantering av mjukvara som fungerar som en plattform för att skapa applikationsapplikationer, vilket säkerställer att de senare interagerar med processorn, RAM, in-/utgångsenheter och nätverksutrustning. Systemmjukvara skapar en speciell abstraktion i form av gränssnitt som hjälper till att skapa applikationsprogram utan att fördjupa sig i detaljer om hur själva hårdvaran fungerar.
Triplett själv definierar systemprogrammering som "allt som inte är en applikation." Det inkluderar saker som BIOS, firmware, bootloaders och operativsystemkärnor, olika typer av inbäddad lågnivåkod och implementeringar av virtuella maskiner. Intressant nog tror Triplett att en webbläsare också är systemprogramvara, eftersom webbläsaren för länge sedan har blivit mer än "bara ett program", och blivit en fristående "plattform för webbplatser och webbapplikationer."
Tidigare var de flesta systemprogram, inklusive BIOS, bootloaders och firmware, skrivna i assemblerspråk. På 1960-talet började experiment att tillhandahålla hårdvarustöd för högnivåspråk, vilket ledde till skapandet av språk som PL/S, BLISS, BCPL och ALGOL 68.
Sedan, på 1970-talet, skapade Dennis Ritchie programmeringsspråket C för operativsystemet Unix. Skapat i programmeringsspråket B, som inte ens hade skrivstöd, fylldes C med kraftfulla funktioner på hög nivå som var bäst lämpade för att skriva operativsystem och drivrutiner. Flera komponenter i UNIX, inklusive dess kärna, skrevs så småningom om i C. Därefter skrevs även många andra systemprogram, inklusive Oracle-databasen, mycket av Windows-källkoden och operativsystemet Linux, i C.
C har fått ett enormt stöd i denna riktning. Men exakt vad fick utvecklare att byta till det? Triplett menar att för att motivera utvecklare att byta från ett programmeringsspråk till ett annat måste det senare först tillhandahålla nya funktioner utan att förlora gamla funktioner.
För det första måste språket erbjuda "rimligt imponerande" nya funktioner. "Han kunde inte vara bättre. Det måste vara betydligt bättre för att motivera den ansträngning och den tekniska tiden det tar att göra omställningen”, förklarar han. Jämfört med assemblerspråk hade C mycket att erbjuda. Det stödde något typsäkert beteende, gav bättre portabilitet och prestanda med högnivåkonstruktioner och genererade mycket mer läsbar kod överlag.
För det andra måste språket ge stöd för gamla funktioner, vilket innebär att utvecklare i historien om övergången till C måste vara säkra på att det inte var mindre funktionellt än assemblerspråk. Triplett förklarar: "Ett nytt språk kan inte bara bli bättre, det måste också vara lika bra." Förutom att vara snabbare och stödja vilken datatyp som helst som assemblerspråk kunde använda, hade C också vad Triplett kallade en "escape hatch" – det stödde nämligen att infoga assemblerspråkkod inom sig själv.
Triplett menar att C nu håller på att bli vad assemblerspråk var för många år sedan. "C är den nya montören", förklarar han. Nu letar utvecklare efter ett nytt språk på hög nivå som inte bara ska lösa de problem som har samlats i C som inte längre går att fixa, utan också erbjuda spännande nya funktioner. Ett sådant språk måste vara tillräckligt övertygande för att få utvecklare att byta till det, måste vara säkert, tillhandahålla automatisk minneshantering och mycket mer.
"Alla språk som vill bli bättre än C måste erbjuda mycket mer än bara buffertspillskydd om det verkligen vill vara ett övertygande alternativ. Utvecklare är intresserade av användbarhet och prestanda, skriver kod som är självförklarande och gör mer arbete på färre rader. Säkerhetsfrågor måste också åtgärdas. Användarvänlighet och prestanda går hand i hand. Ju mindre kod du behöver skriva för att uppnå något, desto mindre möjlighet har du att göra några misstag, säkerhetsrelaterade eller inte”, förklarar Triplett.
Jämförelse av Rust och C
Redan 2006 började Graydon Hoare, en Mozilla-anställd, skriva Rust som ett personligt projekt. Och 2009 började Mozilla sponsra utvecklingen av Rust för sina egna behov, och utökade även teamet för att ytterligare utveckla språket.
En av anledningarna till att Mozilla var intresserad av det nya språket är att Firefox skrevs i över 4 miljoner rader C++-kod och hade en hel del kritiska sårbarheter. Rust byggdes med säkerhet och samtidighet i åtanke, vilket gör det till ett idealiskt val för att skriva om många av Firefoxs komponenter som en del av Quantum-projektet för att helt omforma webbläsarens arkitektur. Mozilla använder också Rust för att utveckla Servo, en HTML-renderingsmotor som så småningom kommer att ersätta den nuvarande Firefox-renderingsmotorn. Många andra företag har börjat använda Rust för sina projekt, inklusive Microsoft, Google, Facebook, Amazon, Dropbox, Fastly, Chef, Baidu och många fler.
Rust löser ett av de viktigaste problemen med språket C. Det erbjuder automatisk minneshantering så att utvecklare inte behöver allokera manuellt och sedan frigöra det för varje objekt i applikationen. Det som skiljer Rust från andra moderna språk är att den inte har en skräpsamlare som automatiskt tar bort oanvända objekt från minnet, och inte heller har den den runtime-miljö som krävs för att få den att fungera, som Java Runtime Environment för Java. Istället har Rust begreppen ägande, upplåning, referenser och livstid. "Rust har ett system för att deklarera anrop till ett objekt för att indikera om ägaren använder det eller bara lånar det. Om du bara lånar ett objekt kommer kompilatorn att hålla reda på detta och se till att originalet ligger kvar så länge du refererar till det. Rust kommer också att se till att objektet tas bort från minnet så snart användningen är klar, och infogar ett motsvarande anrop i koden vid kompilering utan extra tid, säger Triplett.
Avsaknaden av en inbyggd körtid kan också betraktas som en positiv egenskap hos Rust. Triplett menar att språken den körs på är svåra att använda som systemprogrammeringsverktyg. Som han förklarar: "Du måste initiera den här körtiden innan du kan anropa någon kod, du måste använda den här körtiden för att anropa funktioner, och själva körtiden kan köra ytterligare kod bakom din rygg vid oväntade tider."
Rust strävar också efter att tillhandahålla säker parallellprogrammering. Samma funktioner som gör det minnessäkert håller reda på saker som vilken tråd som äger vilket objekt och vilka objekt som kan föras mellan trådar och vilka som behöver ett lås.
Alla dessa funktioner gör Rust tillräckligt övertygande för utvecklare att välja det som ett nytt verktyg för systemprogrammering. Men när det gäller parallell beräkning är Rust fortfarande lite efter C.
Triplett har för avsikt att skapa en särskild arbetsgrupp som kommer att fokusera på att introducera de nödvändiga funktionerna i Rust så att den helt kan vara lika med, överträffa och ersätta C inom systemprogrammering. I , tillägnad sitt tal, sa han att "FFI/C Parity-gruppen håller på att skapas och har ännu inte börjat arbeta", för nu är han redo att svara på alla frågor, och i framtiden kommer han definitivt att publicera omedelbara planer för utvecklingen av Rust som en del av hans initiativ för alla intresserade.
Det kan antas att FFI/C Parity-gruppen först och främst kommer att fokusera på att förbättra stödet för flera trådar i Rust, introducera stöd för BFLOAT16, ett flyttalsformat som har dykt upp i de nya Intel Xeon Scalable-processorerna, samt att stabilisera monteringen kodinsättningar.
Källa: 3dnews.ru