Rust vs. C beágyazott firmware-hez: melyiket válaszd a projektedhez?

Ha dolgozik beágyazott firmware-t használsz, és a Rust és a C között vitatkozolNincs egyedül. Egyre több csapat gondolkodik azon, hogy érdemes-e továbbra is a hagyományos C-re hagyatkozni, vagy elkezdeni projektjeik egy részét Rust-ra migrálni, különösen akkor, ha a biztonság, a karbantarthatóság és az összekapcsolt rendszerek is szerepet játszanak.

Ebben a cikkben nyugodtan, de egyenesen lebontjuk a következőket: Mit tesz hozzá a Rust és a C a beágyazott rendszerek kontextusában?Memóriabiztonság, teljesítmény, párhuzamos működés, eszközök, ökoszisztéma, tanulási görbe, és illeszkedés valós projektekbe, amelyek sok régi kódot tartalmaznak. Az ötlet az, hogy egyértelmű kritériumok alapján eldönthesd, mikor van értelme a C-nél maradni, és mikor érdemes a Rust-ot választani a firmware-ben.

Kontextus: Miért kulcsfontosságú a Rust kontra C párharc a beágyazott firmware-ekben

A világban nagyon alacsony szintű rendszerek, mikrokontrollerek és IoT eszközökA C továbbra is vitathatatlan király. Évtizedek óta szinte mindennek az anyanyelve, ami számítógéphez csatlakozik: illesztőprogramoknak, gyártók HAL-jainak, RTOS-ainak, TCP/IP-vermeknek, rendszerbetöltőknek és sok másnak. Ez több millió sornyi kódot jelent, amelyek éles környezetben futnak olyan szektorokban, mint az autóipar, az ipar, az energiaipar és a szórakoztatóelektronika.

Rust, a maga részéről, Sokkal később született, egyértelmű megszállottsággal.Memória- és párhuzamos működési biztonságot nyújtani szemétgyűjtés nélkül és az alacsony szintű teljesítmény feláldozása nélkül. Bár kezdetben nagyobb rendszerkörnyezetekben (böngészők, backendek, WebAssembly) szerzett magának népszerűséget, a közösség jelentős előrelépéseket tett a beágyazott rendszerek terén a projekteknek, a ládáknak és a „biztonság az első” filozófiának köszönhetően.

A kérdés, amit sok csapat feltesz magának manapság, egyszerű, de kellemetlen: Van értelme folyamatosan új firmware-t írni C-ben?A mutatók és túlcsordulások minden kockázatával együtt, vagy itt az ideje, hogy áttérjünk a Rust-ra, legalább a rendszer legkritikusabb részein?

Továbbá ez a döntés nem vákuumban születik. Figyelembe kell venni, hogy a biztonsági hibák jó része A csatlakoztatott eszközökön megjelenő hibák a C/C++ memóriahibáiból erednek, amire különböző szervezetek és kormányok kezdtek kifejezetten rámutatni, és a kritikus szoftverekhez biztonságosabb nyelvek használatát szorgalmazzák.

Gyökerek, érettség és ökoszisztéma: C veteránként és Rust újoncként

A C nyelv beágyazott környezetben való működési területe néhány tényezőn alapul nehezen figyelmen kívül hagyható történelmi gyökerekAz 70-es évek óta mikrovezérlőket használnak operációs rendszerek, mindenféle firmware és olyan alkalmazások írására, ahol minden bájt és minden CPU-ciklus számít. Erre az alapra építve egy hatalmas, kifejezetten mikrovezérlők számára tervezett fordítóprogramok, könyvtárak, RTOS-ok és hibakereső eszközök ökoszisztémája épült fel.

Ennek a tehetetlenségnek közvetlen következményei vannak: A szilíciumgyártók C nyelven tervezik meg SDK-ikat és példáikatAmikor letöltöd egy új mikrovezérlő támogatási csomagját, jellemzően egy tesztelt C fordítót, C illesztőprogramokat, referencia példákat és nagyon kifinomult integrációt találsz a saját vagy GCC-alapú IDE-kkel. Ezáltal gyakorlatilag bármilyen platformon azonnal elindíthatsz egy C projektet.

Rozsda, összehasonlítva, Újoncként érkezik, tele lelkesedéssel és gyökeresen más megközelítéssel.A közösség mindössze néhány év alatt egyre robusztusabb ökoszisztémát épített ki a beágyazott rendszerek számára, amelyet olyan ládák támogatnak, mint a beágyazott halTöbb tucat ARM Cortex-M és RISC-V mikrovezérlőre, valamint teljes egészében Rust nyelven írt valós idejű operációs rendszerekre vagy beágyazott alkalmazáskeretrendszerekre jellemző HAL-családok.

Azonban még ma is vannak olyan területek, ahol A Rust támogatás nem olyan azonnali vagy hivatalos, mint amilyennek látszik.Nagyon specifikus architektúrákban, ritka chipekben vagy nagyon zárt, saját fejlesztésű SDK-kban gyakori, hogy a Rust „alapértelmezett” támogatása még nem érhető el, és C burkolókat kell használni, vagy manuálisan kell dolgozni a blokkokkal. nem biztonságos bizonyos funkciók eléréséhez.

Összefoglalva, míg C a következők előnyeit élvezi: Évtizedeknyi érettség, ipari eszközök és hivatalos támogatás Szinte minden beágyazott platformon a Rust részben kompenzálja ezt a hagyományhiányt modern dizájnnal, nagyon aktív közösséggel és a biztonságra való egyértelmű összpontosítással, de bizonyos nagyon specifikus piaci résekben még mindig a terjeszkedés fázisában van.

Memóriabiztonság: C manuális modell vs. tulajdonjog Rustban

C nyelven a memóriakezelés ugyanolyan hatékony, mint amilyen veszélyes. A nyelv lehetővé teszi ezt. minden lefoglalt és felszabadított bájt részletes szabályozásáraAzonban gyakorlatilag semmilyen korlátozást nem szab: te döntöd el, hogy mikor használsz malloc-ot, mikor szabadítasz fel memóriát, hogyan kezeled a mutatókat és hogyan éred el a tömböket. Ez nagy szabadságot biztosít, de egyben megnyitja az utat a klasszikus hibák előtt is, mint például a puffer túlcsordulás, a lelógó mutatók, a már felszabadított memória újrafelhasználása és a nehezen nyomon követhető szivárgások.

Ez a valóság nem elméleti: Becslések szerint a C/C++ nyelven írt szoftverek biztonsági réseinek nagy része Ezek a problémák memóriahibákból erednek. Beágyazott firmware-ekben ez különösen kritikus, mivel nemcsak összeomlásokat okozhat, hanem kiszámíthatatlan valós idejű viselkedést vagy biztonsági réseket is a csatlakoztatott eszközökben.

Rust ezt a problémát egy egészen más megközelítéssel kezeli, amely a sajátján alapul. tulajdonlási és hitelrendszerA Rustban minden értéknek egyetlen tulajdonosa van, amelynek élettartamát a fordító egyértelműen meghatározza. Amikor valami kilép a hatókörből, a memóriája determinisztikusan felszabadul, szemétgyűjtés nélkül. Ugyanakkor a referenciáknak szigorú szabályoknak kell megfelelniük: nem lehetnek érvénytelen referenciák, és nem keverhetők párhuzamos olvasások és írások biztonságos mechanizmusok nélkül.

Ez arra utal Sok memóriahiba egyszerűen megakadályozza a fordítástHa az áthelyezés után megpróbálod használni az adatokat, a fordító figyelmeztet. Ha két módosítható hivatkozást szeretnél ugyanarra az erőforrásra, a Rust nem engedélyezi, amíg be nem írod a megfelelő szakaszt. nem biztonságos és elfogadja a következményeket. Továbbá, a tömbökhöz és dinamikus gyűjteményekhez való hozzáférés alapértelmezés szerint határérték-ellenőrzéseket végez, megakadályozva a tipikus túlcsordulásokat, különösen a fejlesztői buildekben.

A gyakorlati eredmény az, hogy míg a C-ben a tapasztalatodra, a kódáttekintésekre és külső eszközökre támaszkodsz a memóriahibák kiküszöbölése érdekében, a Rustban maga a nyelv működik. a biztonságos memóriakezelés őre még mielőtt a firmware futna a mikrovezérlőn.

Teljesítmény és determinizmus erőforrás-korlátos rendszerekben

Az egyik oka annak, hogy a C évtizedek óta a firmware trónján marad, az az, hogy Rendkívül kiszámítható teljesítményt nyújtTudod, mely utasítások fognak végrehajtódni, bájtonként finomhangolhatod a memóriahasználatot, és kiküszöbölheted a felesleges többletterhelést. Korlátozott RAM-mal és nagyon szigorú valós idejű követelményekkel rendelkező rendszerekben ez a képesség, hogy a hardvert a határaiig feszegesd, továbbra is hatalmas előnyt jelent.

A rozsdát azonban a nulláról úgy tervezték, hogy nulla költségű absztrakciókEz azt jelenti, hogy a nyelv által kínált magas szintű konstrukciók közül sok (itátorok, generikusok, hibatípusok stb.) fordításkor optimalizálva van, hogy a gépi kód ugyanolyan hatékony legyen, mint amit kézzel írnánk C-ben. Nincs szemétgyűjtő, amely kiszámíthatatlan szüneteket hozna létre, és a fordító képes eltávolítani a legtöbb biztonsági ellenőrzést az éles buildekben, ha be tudja bizonyítani, hogy azok szükségtelenek.

A valós rendszerek összehasonlítása kimutatta, hogy A rozsda jellemzően eléri vagy nagyon közelíti a C teljesítményét.sőt, bizonyos esetekben meg is haladják azt a modern fordítóprogram-optimalizálásoknak és a magas szintű kód írásának képességének köszönhetően, amelyet az optimalizáló hatékonyabban tud elemezni. Nagyon szűk beágyazott környezetekben azonban a végső bináris méret és a memóriahasználat továbbra is fontos figyelembe veendő tényezők.

A firmware fejlesztő szempontjából a lényeg az, hogy A rozsda nem okoz automatikus teljesítménycsökkenéstTovábbra is a fémhez közel dolgozhatsz, alacsony szintű adatszerkezeteket kezelhetsz, és szükség esetén blokkokhoz is folyamodhatsz. nem biztonságos nagyon korlátozott a regiszterekkel vagy adott hardverekkel való interakcióra, a kód többi részét a nyelv biztonsági garanciái alatt tartva.

Következésképpen a legtöbb beágyazott projekt esetében, ahol a C teljesítménye kritikus követelmény volt, A rozsda tökéletesen versenyképes, azzal a további előnnyel, hogy drasztikusan csökkenti a memóriahibák és a meghatározatlan viselkedés felületét.

Párhuzamosság és valós idő: manuális fegyelem C-ben versus típusbiztonság Rustban

Amikor elkezdjük bevezetni a párhuzamos feladatokat, megszakításokat és a megosztott erőforrás-hozzáférést a firmware-ben, a C nyelv biztosítja az összes szükséges elemet: RTOS, szálak, sorok, szemaforok, mutexek, atomi változókA probléma az, hogy a nyelv ismét azt feltételezi, hogy tudod, mit csinálsz. Semmi sem akadályoz meg abban, hogy ugyanazt a változót több védelem nélküli feladatból olvasd és írd, vagy hogy olyan zárolási sémát tervezz, amely nehezen reprodukálható patthelyzetet eredményez.

Ezekben az esetekben a biztonság a következőktől függ: csapatfegyelem, kódáttekintések és tesztelésA megfelelő eszközökkel robusztus, párhuzamos rendszerek építhetők C nyelven, de a bonyolult versenyhelyzet kialakulásának valószínűsége valós, különösen a firmware növekedésével és összetettségével.

A rozsda magában foglalja a párhuzamossági biztonság közvetlenül a típusrendszerbenJellemvonásokon keresztül Küldés y SzinkronizálásA fordítóprogram dönti el, hogy mely típusok mozgathatók vagy oszthatók meg biztonságosan a szálak között. A kölcsönzési szabályok itt is érvényesek: több kontextusból történő egyidejű, módosítható hozzáférés nem megengedett biztonságos struktúrák, például mutexek, RwLock vagy atomi számlálású referenciatípusok használata nélkül.

A következmény az A memóriaverseny-feltételek nagyrészt tiltottak a tervezés miattHa megfelelő védelem nélkül próbálsz nem biztonságos adatokat átadni egy másik feladatnak, a fordító hibát dob. Természetesen továbbra is előfordulhatnak hibák a magas szintű logikában, de a párhuzamos működési hibák egy egész kategóriája kimarad, mivel nem fordul le.

Olyan firmware-hez, amely elkezdi beépíteni multitasking, intenzív kommunikáció vagy párhuzamos feldolgozásEz a modell további nyugalmat biztosít. Sok csapat pontosan azért értékeli a Rust „félelem nélküli párhuzamos működését”, mert csökkenti a versenyfeltételekhez kapcsolódó, nehezen megtalálható hibák üldözésére fordított időt.

Termelékenység, tanulási görbe és tehetségek elérhetősége

A beágyazott világban a C mellett szóló egyik leggyakrabban ismételt érv a következő: tapasztalt fejlesztők hatalmas bázisa akik már elsajátították a nyelvet és eszközeit. Viszonylag könnyű olyan mérnököket találni, akik könnyedén eligazodnak a mikrovezérlők C kódjában, különösen azokban az ágazatokban, amelyek évtizedek óta fektetnek be ebbe a technológiába.

A rozsda viszont Még mindig kisebb közösséggel rendelkezik a beágyazott térbenSok fejlesztő éppen a C/C++-ról való átállás és tanulás folyamatában van, ami azt jelenti, hogy rövid távon drágább lehet olyan profilokat toborozni, akik mélyreható Rust tapasztalattal rendelkeznek, kifejezetten az alacsony szintű firmware-ekhez.

Ehhez járul még az a tény, hogy A Rust tanulási görbéje kétségtelenül meredekKülönösen az elején. A tulajdonlási modell, a kölcsönzési szabályok, az élettartamok és a változtathatósági korlátok arra kényszerítenek, hogy megváltoztasd a kódodról alkotott gondolkodásmódodat és strukturálásodat. Gyakori, hogy a fordítóprogram az első néhány hónapban sok próbálkozást elutasít, amíg „internalizálod”, hogy mit vár el tőled.

Az érem másik oldala az, hogy miután ez a kezdeti szakasz véget ér, A termelékenység közép- és hosszú távon egyértelműen növekedhetAz a tény, hogy a fordítás során számos hibát észlelnek, csökkenti a hibakeresésre, az ismétlődő tesztelésre és a finom regressziók elvégzésére fordított órákat, ami különösen azoknál a termékeknél észrevehető, amelyeket évekig karban kell tartani, és új funkciókkal kell fejleszteni.

A dokumentáció és a képzési források tekintetében a Rust a következőket kínálja: Magas színvonalon elkészített hivatalos anyagok és egy nagyon oktató közösségA könyvek, tanfolyamok, online dokumentációk és mintatárházak megkönnyítik a teljes csapatok számára a strukturált képzést, bár ez időt és költségvetést igényel rá, amit nem minden projekt engedhet meg magának azonnal.

Fejlesztőeszközök és projekttapasztalat

A beágyazott rendszerek C projektjeiben gyakori, hogy heterogén eszközkeverékEzek közé tartoznak a különféle fordítók, a saját IDE-k, a Makefile-ok vagy a CMake, az egyéni szkriptek, és sok esetben a manuális függőségkezelés. Bár léteznek függőségkezelők, mint például a vcpkg vagy a Conan, nem ritka, hogy minden vállalatnak megvan a saját eszköz- és belső konvenció-koktélja.

C nyelven statikus analízishez, szivárgásészleléshez vagy párhuzamossági problémákhoz általában a következőhöz folyamodunk: külső segédprogramok, mint például a Valgrind, az AddressSanitizer, a ThreadSanitizer vagy specifikus linterekEzek hatékony és jól bevált eszközök, de megfelelően kell integrálni és konfigurálni őket, és gyakran nem részei a csapat összes fejlesztőjének standard munkafolyamatának.

A Rust sokkal egységesebb élményt nyújt a következőknek köszönhetően: Cargo, annak épületrendszere és csomagkezelőjeEgyetlen eszközzel létrehozhatsz projekteket, függőségeket adhatsz hozzá, fordíthatsz, teszteket futtathatsz, dokumentációt generálhatsz és verziókat kezelhetsz. Továbbá az ökoszisztéma olyan eszközöket is tartalmaz, mint például a [eszközök listája]. rustfmt a kód formázásához és Clippy a kétes minőségi minták észlelése és fejlesztések javaslata.

A beágyazott rendszerben ez a homogenitás üdvözlendő, mert Leegyszerűsíti az új adattárak beállítását és a csapatok közötti együttműködést.Egy HAL hozzáadása egy új mikrovezérlőhöz általában annyit tesz, hogy beillesztünk egy ládát a konfigurációs fájlba, és elkezdjük használni, ahelyett, hogy beillesztési útvonalakkal és szétszórt build szkriptekkel kellene bajlódni.

Ez nem cáfolja azt a tényt, hogy néhány nagyon zárt ipari folyamatban, A C eszközök továbbra is kifinomultabb integrációt kínálnak hardverprogramozókkal, JTAG hibakeresőkkel vagy tanúsított környezetekkel. Ezekben az esetekben a Rustnak további munkára lehet szüksége a meglévő eszköztárba való beillesztéséhez, különösen akkor, ha a gyártó még nem kínál hivatalos támogatást.

Integráció a meglévő kóddal és fokozatos bevezetése

Kevés eszköz rendelkezik azzal a luxussal, hogy a firmware frissítését a nulláról kezdhesse. Gyakoribb, hogy jelentős mennyiségű C kód már gyártás alatt áll A Rust átment az auditokon, tanúsítványokon és évekig tartó karbantartáson. Egy teljes átírás Rustban nemcsak rendkívül költséges, de kockázatos is lenne: minden átírt sor potenciális új hibaforrás.

Ebben az összefüggésben a C-nek továbbra is egyértelmű előnye van, hogy Egy C rendszer bővítése további C-vel triviálisRefaktorálhatsz modulokat, modernizálhatod a kódbázis egyes részeit, vagy funkciókat adhatsz hozzá anélkül, hogy egyszerre kellene bevezetned egy új technológiát, ami leegyszerűsíti a kockázatkezelést.

A Rust most úgy van kialakítva, hogy viszonylag jól együtt tud működni a C-vel az FFI-n (Foreign Function Interface) keresztülLehetséges a C függvényeket API-kként elérhetővé tenni, amelyeket a Rust meghívhat, és fordítva, olyan Rust modulokat is létrehozni, amelyek exportálják a C ABI-kkal ellátott interfészeket a meglévő firmware-ből való használatra. Ez a megközelítés lehetővé teszi a fokozatos bevezetést: a legérzékenyebb komponensek (pl. biztonsági modulok vagy összetett elemzők) átírhatók Rustban, miközben a rendszer többi része C-ben marad.

A C és a Rust közötti határok azonban megkövetelik Különös figyelmet kap az adatszerkezetek definíciója, az igazítás, a memóriakezelés és a hívási konvenciók.Ezeket a területeket általában úgy jelölik ki, hogy nem biztonságos A Rust esetében ez azt jelenti, hogy nagyon világos szerződést kell kötni a C világgal a meglepetések elkerülése érdekében. Megfelelő fegyelemmel ez a hibrid stratégia még nagy projektekben is életképesnek bizonyult.

Sok csapat számára ez a megközelítés az együttéléshez ésszerű módja annak, hogy Kezdje el a Rust előnyeit anélkül, hogy évekig tartó C-befektetést pazarolnaUgyanakkor lehetővé teszi, hogy valós tapasztalatokat szerezz az új nyelvvel egy ellenőrzött környezetben, mielőtt a firmware további részeiben elköteleznéd magad mellette.

A C és a Rust tipikus felhasználási esetei beágyazott firmware-ben

A hagyományosabb beágyazott rendszerek területén, pl. egyszerű mikrovezérlők, nagyon szigorú valós idejű követelmények és egyetlen szállítóra fókuszáló ökoszisztémákA C nyelv továbbra is a természetes választás. A példák, a szállítói könyvtárak, a minősített illesztőprogramok és a tapasztalt személyzet elérhetősége nagymértékben csökkenti a kezdeti súrlódásokat és a projekt kockázatait.

Azokban az ágazatokban is, ahol a C-re fókuszáló tanúsítási keretrendszerekPéldául bizonyos autóipari vagy repüléstechnikai szabályozásokban a C nyelv elsődleges nyelvként való megtartása jobban illeszkedik a már kialakult folyamatokhoz, a meglévő statikus elemzőeszközökhöz és azokhoz az auditokhoz, amelyek évek óta erre a technológiai rendszerre támaszkodnak.

A rozsda viszont úgy illik ide, mint a kesztyű. új projektek, ahol a biztonság és a hosszú távú stabilitás prioritást élvezAz internetnek kitett IoT-eszközök, az olyan rendszerek, ahol egy sebezhetőség komoly hatással lehet, vagy az évekig távolról frissítendő firmware-ek nagy hasznot húzhatnak egy olyan nyelvből, amely drasztikusan csökkenti a memóriahibákat, és kikényszeríti a hibák és állapotok explicit kezelését.

Továbbá olyan környezetben, ahol a berendezés nem rendelkezik nagy, dedikált minőségbiztosítási vagy biztonsági osztályokA rozsda egyfajta beépített biztonsági hálóként működik. Számos, a C-ben „ajánlott” gyakorlat (minden mutató ellenőrzése, a hibakódok figyelmen kívül hagyásának elkerülése, az inkonzisztens köztes állapotok elkerülése) kötelezővé válik a kód lefordításához.

Végül, a Rust moduláris megközelítése és ládákból álló ökoszisztémája különösen vonzóvá teszi a következők számára: olyan projektek, amelyek logikát szeretnének megosztani különböző környezetek között (például üzleti logika megosztása a háttérrendszer és a firmware között, vagy elemzők és kriptográfiai könyvtárak újrafelhasználása több platformon), feltéve, hogy az egyes célpontok specifikus alacsony szintű részéről gondoskodnak.

Mindezek után egyértelművé válik a kép: A C továbbra is verhetetlen a folytonosság és a kompatibilitás nyelveként a mai beágyazott firmware-ek nagy részében, míg a Rust nagyon erős versenyzőként pozicionálódik az új fejlesztések terén, ahol a biztonság és a hosszú távú karbantarthatóság ugyanolyan fontos, mint a puszta teljesítmény.

Hogyan döntsünk: gyakorlati kritériumok a nyelv kiválasztásához a következő firmware-ben

A Rust és a C közötti választás egy adott beágyazott projekt esetében ritkán tisztán technikai kérdés; A csapatod valósága, a határidők és az üzleti követelmények is szerepet játszanak.Néhány gyakran döntő tényező a korábbi kód mennyisége, a tanúsítási igények, a biztonsági kritikusság és a csapat betanítására rendelkezésre álló idő.

Ha a szervezete húzódik Évek óta stabil, jól tesztelt C kód bevált folyamatokkalÉs ha a jelenlegi igényeid inkább a funkcionalitás bővítésére irányulnak, mint az architektúra újratervezésére, akkor tökéletesen logikus, hogy a C-nél maradj. A nyelvek kényszerítő ok nélküli váltása több problémát okozhat, mint megoldást, különösen azokban a rendszerekben, amelyek már megfelelnek a teljesítmény- és megbízhatósági céljaiknak.

Másrészt, ha elkezdesz egy új termék, amely nem függ erősen a régi kódtólKülönösen akkor, ha azt tervezed, hogy kapcsolatban maradsz, távolról frissítesz és érzékeny adatokat kezelsz, a Rust bevezetésébe fektetett idő nagyon megéri vállalkozás lehet. A kezdeti tanulási görbét ellensúlyozza egy robusztusabb és könnyebben karbantartható kódbázis az évek során.

Érdemes megfontolni a köztes megoldásokat is, mint például Kezdje el bevezetni a Rust-ot izolált és jól definiált modulokban meglévő projektekből: például olyan kommunikációs rétegek, ahol garantálni szeretné a túlcsordulások elkerülését, vagy olyan komponensek, amelyek kulcsokat és kriptográfiát kezelnek. Ez lehetővé teszi a Rust hatásának gyakorlati értékelését az adott kontextusban, mielőtt átfogóbb döntéseket hozna.

Végső soron ahelyett, hogy egy „összesített győztest” keresnénk, hasznosabb, ha Rustot és C-t úgy látjuk, mint kiegészítő eszközök ugyanazon arzenálon belülMindegyiknek megvannak a maga egyértelmű erősségei és nyilvánvaló korlátai; a lényeg az, hogy mindkettőből a legjobbat hozzuk ki ott, ahol a legtöbb értéket képviselik a firmware életciklusa során.

A nagy képet nézve egyértelmű, hogy A C nyelv vezető szerepet tölt be a beágyazott firmware-ekben a mély gyökereinek, a gyártói támogatásnak és az abszolút hardveres kontrollnak köszönhetően.De a Rust túllépett az újdonságon, és nagyon komoly alternatívává vált az új fejlesztésekben, különösen ott, ahol a biztonság, a biztonságos párhuzamosság és a karbantarthatóság kulcsfontosságú. Sok csapat számára a legésszerűbb megközelítés a C folyamatos használata a Rust fokozatos bevezetésével kombinálva a kritikus területeken, így robusztusabb beágyazott rendszereket építve anélkül, hogy feladnánk mindent, amit az elmúlt évtizedekben tanultunk.