Integreringen av Rust i Linux har haft en hög nivå av acceptans av communityn och utvecklarna
En av de stora problem som har uppstått i utvecklingen av kärnan av Linux under lång tid, är idén att hitta en perfekt kandidat för att byta programmeringsspråk "C" för en mer modern och tills nyligen med ankomsten av Rust, har denna idé inte slutat läggas på bordet.
Med den första förhandstitten av Rust på Linux 6.1, Jag återupplivar spriten hos en stor del av utvecklarna av kärnan och Jonathan Corbet påpekar att "det fortfarande inte skulle finnas tillräckligt med rost i kärnan för att göra något intressant", införandet av detta språk har återupplivat debatten om behovet av att förkasta C-språket till förmån för Rust i termer av av systemprogrammering. Frågan delar utvecklargemenskapen.
asahi linya tog på sig uppdraget att utveckla en drivrutin för grafikprocessor (GPU) för Mac M1 i Rust.
Om din jämförelse mellan Rust och C-språk nämner att:
"Det finns absolut ingen chans att du inte skulle behöva hantera samtidig åtkomsthantering, försök att komma åt minnesområden efter utgivningen och alla möjliga andra problem om du skulle skriva detta i C. Alla samtidiga problem försvinner med Rust! Minnet frigörs när det behövs! När du väl lärt dig hur du får Rust att fungera för dig tror jag att det kommer att guida dig till att skriva anständig kod, även bortom språkets säkerhetslöften. Det är verkligen magiskt! »
"Det finns en hel del debatt om huruvida Rust är användbar i kärnan eller inte... enligt min erfarenhet är det mycket mer användbart än jag någonsin föreställt mig!" ", tillägger hon.
Dina kommentarer upprepar sig typ från en sammanställning av tekniska skäl som förmodligen motivera att avstå från C-språket till förmån för Rust. Faktum är att 15,9 % av de 2288 20 sårbarheter som har påverkat Linux-kärnan på XNUMX år (siffror från Common Vulnerabilities and Exposure (CVE)-ordboken) är kopplade till brister i C-språket, problem relaterade till minneshantering: buffertspill , tilldelningar som inte frigjorts, tillgång till ogiltiga eller frigjorda minnesområden, etc.
Dessutom är de huvudsakliga underhållarna av Linux-kärnan bekanta med C-språket, vars ålder redan anses vara i den 3:e åldern. En ny generation underhållare vars åldersgrupp är i trettioårsåldern är på frammarsch, och därmed kommer svårigheten att hitta underhållare för Linux-kärnan sannolikt att öka om utvecklingen fortsätter i språket C. Orsaker till att Linus Torvalds öppnade dörren till kärnan utveckling i Rust.
På frågan om möjligheten att förkasta C-språket, skaparen av C-språket listar ett antal anledningar till varför initiativ sannolikt kommer att misslyckas som går i denna riktning:
VS Language Toolchain
C-språket är inte bara själva språket, utan också alla utvecklingsverktyg som utvecklats för detta språk.
Vill du göra en statisk analys av din källkod? – Det är många som jobbar med detta för C. Verktyg för att upptäcka minnesläckor, dataracer och andra fel? Det finns många, även om ditt språk är bättre rustat.
Om du vill rikta in dig på en föga känd plattform, är chansen stor att du använder C. C:s status eftersom datoranvändningens lingua franca idag gör det värt skrivverktyg för, och många verktyg skrivs.
Om någon har en fungerande verktygskedja:
varför riskera att byta språk? Ett "bättre C" borde generera mycket extra produktivitet för att motivera tiden som ägnas åt att sätta upp en ny verktygskedja. Om detta är möjligt återstår att se.
Osäkerheterna i ett nytt språk
Innan ett språk når mognad, är det sannolikt buggy. och är avsevärt modifierad för att ta itu med språkets semantiska frågor. Och överensstämmer språket ens med annonsen? Det kan erbjuda något som "exceptionella kompileringstider" eller "snabbare än C", men dessa mål blir svåra att uppnå när språket lägger till
Och underhållarna? Visst, du kan punga med ett språk med öppen källkod, men jag tvivlar på att många företag skulle vara intresserade av att använda ett språk som de kan tvingas behålla senare. Att satsa på ett nytt språk är en stor risk.
Det faktum att språket kanske inte är tillräckligt bra
Tar språket upp de faktiska smärtpunkterna för C?
Det visar sig att Folk är inte alltid överens om vad C:s svagheter är. Minnesallokering, array- och stränghantering är ofta knepigt, men med rätt bibliotek och en bra minnesstrategi kan de minimeras.
Tar inte språket upp problem som avancerade användare egentligen inte bryr sig om? Om så är fallet kan dess faktiska värde vara mycket lägre än förväntat.
Och ännu värre, tänk om språket utelämnar avgörande egenskaper som finns i C? Funktioner som avancerade C-programmerare förlitar sig på? Denna risk ökar om språkdesignern inte har använt mycket C, utan kommer från C++, Java osv.
Brist på erfarna utvecklare för ett nytt språk
Ett nytt språk kommer naturligtvis att ha en mycket mindre pool av erfarna utvecklare. För alla medelstora eller stora företag är detta ett stort problem. Ju fler utvecklare som är tillgängliga för ett företag, desto bättre har det.
Dessutom, om företaget har erfarenhet av att rekrytera C-utvecklare, vet de inte hur de ska rekrytera för detta nya språk.
Slutligen, om du är intresserad av att veta mer om det, kan du konsultera detaljer i följande länk.