På den nylige Open Source Technology Summi (OSTS) , en senioringeniør hos Intel, sa at selskapet hans er interessert i at Rust skal nå "paritet" med C-språket som fortsatt dominerer systemer og utvikling på lavt nivå i nær fremtid. Under tittelen "Intel and Rust: The Future of Systems Programming," snakket han også om historien til systemprogrammering, hvordan C ble standard systemprogrammeringsspråk, hvilke funksjoner i Rust som gir det en fordel fremfor C, og hvordan det kunne fullstendig erstatte C i dette programmeringsfeltet.
Systemprogrammering er utvikling og administrasjon av programvare som fungerer som en plattform for å lage applikasjonsapplikasjoner, som sikrer at sistnevnte samhandler med prosessoren, RAM, inngangs-/utgangsenheter og nettverksutstyr. Systemprogramvare skaper en spesiell abstraksjon i form av grensesnitt som hjelper til med å lage applikasjonsprogramvare uten å fordype seg i detaljene om hvordan selve maskinvaren fungerer.
Triplett selv definerer systemprogrammering som "alt som ikke er en applikasjon." Det inkluderer ting som BIOS, fastvare, oppstartslastere og operativsystemkjerner, ulike typer innebygd lavnivåkode og virtuelle maskinimplementeringer. Interessant nok mener Triplett at en nettleser også er systemprogramvare, siden nettleseren for lenge siden har blitt mer enn "bare et program", og blitt en frittstående "plattform for nettsteder og nettapplikasjoner."
Tidligere ble de fleste systemprogrammene, inkludert BIOS, bootloadere og fastvare, skrevet på assemblerspråk. På 1960-tallet begynte eksperimenter å gi maskinvarestøtte for språk på høyt nivå, noe som førte til opprettelsen av språk som PL/S, BLISS, BCPL og ALGOL 68.
Så, på 1970-tallet, skapte Dennis Ritchie C-programmeringsspråket for Unix-operativsystemet. Laget i B-programmeringsspråket, som ikke engang hadde skrivestøtte, var C fylt med kraftige høynivåfunksjoner som var best egnet for å skrive operativsystemer og drivere. Flere komponenter av UNIX, inkludert kjernen, ble til slutt skrevet om i C. Deretter ble mange andre systemprogrammer, inkludert Oracle-databasen, mye av Windows-kildekoden og Linux-operativsystemet, også skrevet i C.
C har fått enorm støtte i denne retningen. Men hva var det egentlig som fikk utviklere til å bytte til det? Triplett mener at for å motivere utviklere til å bytte fra ett programmeringsspråk til et annet, må sistnevnte først gi nye funksjoner uten å miste gamle funksjoner.
For det første må språket tilby "rimelig imponerende" nye funksjoner. «Han kunne ikke vært bedre. Det må være betydelig bedre for å rettferdiggjøre innsatsen og ingeniørtiden det tar å gjennomføre overgangen, forklarer han. Sammenlignet med assemblerspråk, hadde C mye å tilby. Den støttet noe typesikker oppførsel, ga bedre portabilitet og ytelse med konstruksjoner på høyt nivå, og genererte mye mer lesbar kode totalt sett.
For det andre må språket gi støtte for gamle funksjoner, noe som betyr at i historien til overgangen til C måtte utviklere være sikre på at det ikke var mindre funksjonelt enn assemblerspråk. Triplett forklarer: "Et nytt språk kan ikke bare bli bedre, det må også være like bra." I tillegg til å være raskere og støtte enhver datatype som assembly-språket kunne bruke, hadde C også det Triplett kalte en "escape hatch" - nemlig den støttet å sette inn assembly-språkkode i seg selv.
Triplett mener at C nå er i ferd med å bli det assemblerspråket var for mange år siden. "C er den nye montøren," erklærer han. Nå leter utviklere etter et nytt språk på høyt nivå som ikke bare skal løse problemene som har samlet seg i C som ikke lenger kan fikses, men også tilby spennende nye funksjoner. Et slikt språk må være overbevisende nok til å få utviklere til å bytte til det, må være sikkert, gi automatisk minneadministrasjon og mye mer.
"Alle språk som ønsker å være bedre enn C må tilby mye mer enn bare bufferoverløpsbeskyttelse hvis det virkelig ønsker å være et overbevisende alternativ. Utviklere er interessert i brukervennlighet og ytelse, og skriver kode som er selvforklarende og gjør mer arbeid på færre linjer. Sikkerhetsproblemer må også tas opp. Brukervennlighet og ytelse går hånd i hånd. Jo mindre kode du må skrive for å oppnå noe, jo mindre mulighet har du til å gjøre feil, sikkerhetsrelatert eller ikke», forklarer Triplett.
Sammenligning av Rust og C
Tilbake i 2006 begynte Graydon Hoare, en Mozilla-ansatt, å skrive Rust som et personlig prosjekt. Og i 2009 begynte Mozilla å sponse utviklingen av Rust for sine egne behov, og utvidet også teamet for å videreutvikle språket.
En av grunnene til at Mozilla var interessert i det nye språket er at Firefox ble skrevet i over 4 millioner linjer med C++-kode og hadde ganske mange kritiske sårbarheter. Rust ble bygget med sikkerhet og samtidighet i tankene, noe som gjør det til et ideelt valg for å omskrive mange av Firefoxs komponenter som en del av Quantum-prosjektet for å fullstendig redesigne nettleserens arkitektur. Mozilla bruker også Rust for å utvikle Servo, en HTML-gjengivelsesmotor som til slutt vil erstatte den nåværende Firefox-gjengivelsesmotoren. Mange andre selskaper har begynt å bruke Rust for sine prosjekter, inkludert Microsoft, Google, Facebook, Amazon, Dropbox, Fastly, Chef, Baidu og mange flere.
Rust løser et av de viktigste problemene i C-språket. Det tilbyr automatisk minnebehandling slik at utviklere ikke trenger å tildele og deretter frigjøre det manuelt for hvert objekt i applikasjonen. Det som gjør Rust forskjellig fra andre moderne språk er at den ikke har en søppeloppsamler som automatisk fjerner ubrukte objekter fra minnet, og den har heller ikke kjøretidsmiljøet som kreves for å få det til å fungere, som Java Runtime Environment for Java. I stedet har Rust begrepene eierskap, lån, referanser og levetid. "Rust har et system for å deklarere anrop til et objekt for å indikere om eieren bruker det eller bare låner det. Hvis du bare låner et objekt, vil kompilatoren holde styr på dette og sørge for at originalen forblir på plass så lenge du refererer til den. Rust vil også sørge for at objektet fjernes fra minnet umiddelbart etter at bruken er fullført, ved å sette inn et tilsvarende kall i koden på kompileringstidspunktet uten ekstra tid, sier Triplett.
Mangelen på en naturlig kjøretid kan også betraktes som en positiv egenskap ved Rust. Triplett mener at språkene den kjører på er vanskelige å bruke som systemprogrammeringsverktøy. Som han forklarer: "Du må initialisere denne kjøretiden før du kan kalle noen kode, du må bruke denne kjøretiden til å kalle opp funksjoner, og selve kjøretiden kan kjøre ekstra kode bak ryggen din på uventede tidspunkter."
Rust streber også etter å gi sikker parallell programmering. De samme funksjonene som gjør det minnesikkert holder styr på ting som hvilken tråd som eier hvilket objekt og hvilke objekter som kan føres mellom tråder og hvilke som trenger en lås.
Alle disse funksjonene gjør Rust overbevisende nok til at utviklere kan velge det som et nytt verktøy for systemprogrammering. Men når det gjelder parallell databehandling, er Rust fortsatt litt bak C.
Triplett har til hensikt å opprette en spesiell arbeidsgruppe som skal fokusere på å introdusere de nødvendige funksjonene i Rust slik at den fullt ut kan like, overgå og erstatte C innen systemprogrammering. I , dedikert til talen hans, sa han at "FFI/C Parity-gruppen er i ferd med å opprettes og har ennå ikke begynt arbeidet," for nå er han klar til å svare på alle spørsmål, og i fremtiden vil han definitivt publisere umiddelbare planer for utviklingen av Rust som en del av hans initiativ for alle interesserte.
Det kan antas at FFI/C Parity-gruppen først og fremst vil fokusere på å forbedre multi-threading-støtten i Rust, introdusere støtte for BFLOAT16, et flyttallformat som har dukket opp i de nye Intel Xeon Scalable-prosessorene, samt stabilisering av montering. kodeinnsettinger.
Kilde: 3dnews.ru