A Rust Linuxba való integrációját a közösség és a fejlesztők nagymértékben elfogadták
Az egyik a kernel fejlesztése során felmerült főbb problémák a Linuxot sokáig, az az ötlet, hogy tökéletes jelöltet találjunk a programozási nyelv megváltoztatására "C" egy modernebbre, és egészen a közelmúltig a Rust érkezésével ez az ötlet nem szűnt le az asztalra.
A Rust első előzetesével Linux 6.1 rendszeren, A fejlesztők nagy részénél felélesztem a lelket a kernelből, és Jonathan Corbet rámutat, hogy "még mindig nem lenne elég Rust a kernelben ahhoz, hogy bármi érdekeset csináljon", ennek a nyelvnek a felvétele újraindította a vitát arról, hogy el kell-e vetni a C nyelvet Rust javára. a rendszerprogramozásról. A kérdés megosztja a fejlesztői közösséget.
asahi linya magára vállalta a grafikus feldolgozóegység (GPU) meghajtó fejlesztését a Mac M1-hez Rustban.
A Rust és a C nyelvek összehasonlításáról megemlíti, hogy:
"Egyáltalán nincs esély arra, hogy ne kelljen foglalkoznia a párhuzamos hozzáférés-kezeléssel, a kiadás utáni kísérletekkel a memóriaterületek elérésére, és mindenféle egyéb problémával, ha ezt C-ben írnád. Minden párhuzamossági probléma megszűnik a Rust-tal! A memória szükség esetén felszabadul! Ha megtanulja, hogyan kell a Rustot az Ön számára működőképessé tenni, azt hiszem, ez elvezeti Önt a tisztességes kód írásához, még a nyelv biztonsági ígéreteit meghaladóan is. Tényleg varázslatos! »
"Sok vita folyik arról, hogy a Rust hasznos-e a kernelben vagy sem... tapasztalataim szerint sokkal hasznosabb, mint azt valaha is elképzeltem!" "- teszi hozzá.
A megjegyzéseid ismétlődnek technikai okok összeállításából, hogy valószínűleg indokolja a C nyelv elhagyását Rust javára. Valójában a Linux kernelt 15,9 év alatt érintett 2288 sebezhetőség 20%-a (a Common Vulnerabilities and Exposure (CVE) szótár adatai) a C nyelv hibáihoz, a memóriakezeléssel kapcsolatos problémákhoz kapcsolódik: puffer túlcsordulás , fel nem szabadított allokációk, hozzáférés érvénytelen vagy felszabadult memóriaterületekhez stb.
Ezen kívül a Linux kernel fő karbantartói ismerik a C nyelvet, amelynek életkora már a 3. életkorban van. A harmincas éveiket taposó karbantartók új generációja növekszik, így a Linux kernelhez való karbantartók megtalálásának nehézségei valószínűleg tovább nőnek, ha a fejlesztés C nyelven folytatódik. fejlesztés Rustban.
A C nyelv elvetésének lehetőségével kapcsolatban a C nyelv megalkotója számos okot sorol fel, amelyek miatt a kezdeményezések valószínűleg kudarcot vallanak amelyek ebbe az irányba mennek:
A VS nyelvi eszközlánc
A C nyelv nem csak maga a nyelv, hanem az ehhez a nyelvhez kifejlesztett összes fejlesztőeszköz is.
Szeretnéd statikus elemzést végezni a forráskódodban? – Sokan dolgoznak ezen a C. Eszközök memóriaszivárgások, adatversenyek és egyéb hibák észlelésére? Sok van, még akkor is, ha a nyelved jobban felszerelt.
Ha egy kevéssé ismert platformot szeretne megcélozni, valószínűleg C. C státuszát használja, mint a számítástechnika lingua franca-ja, ezért érdemes eszközöket írni, és sok eszközt írnak.
Ha valakinek van működő szerszámlánca:
miért kockáztatnánk a nyelv megváltoztatását? A "jobb C"-nek sok további termelékenységet kell generálnia, hogy motiválja az új eszközlánc létrehozására fordított időt. Hogy ez lehetséges-e, az majd kiderül.
Egy új nyelv bizonytalanságai
Mielőtt egy nyelv elérné az érettséget, valószínűleg hibás lesz. és jelentősen módosul a nyelv szemantikai kérdéseinek kezelésére. És a nyelvezet összhangban van a hirdetéssel? Valami olyasmit kínálhat, mint „kivételes fordítási idők” vagy „gyorsabb, mint a C”, de ezek a célok nehezen érhetők el, ha a nyelv hozzáadja a
És a fenntartók? Természetesen lehet nyílt forráskódú nyelvet is használni, de kétlem, hogy sok céget érdekelne egy olyan nyelv használata, amelyet később esetleg kénytelenek megtartani. Az új nyelvre való fogadás nagy kockázatot jelent.
Az a tény, hogy a nyelv nem biztos, hogy elég jó
A nyelv foglalkozik a C tényleges fájdalompontjaival?
Kiderül, hogy Az emberek nem mindig értenek egyet abban, hogy mik a C gyengeségei. A memóriafoglalás, a tömbök és karakterláncok kezelése gyakran bonyolult, de megfelelő könyvtárakkal és jó memóriastratégiával minimalizálhatók.
A nyelv nem oldja meg azokat a problémákat, amelyek a haladó felhasználókat nem igazán érdeklik? Ha igen, akkor a tényleges értéke jóval alacsonyabb lehet a vártnál.
És ami még rosszabb, mi van akkor, ha a nyelv kihagyja a C-ben jelenlévő alapvető jellemzőket? Funkciók, amelyekre a haladó C programozók támaszkodnak? Ez a kockázat megnő, ha a nyelvi tervező nem sokat használt C-t, de C++-ból, Java-ból stb.
Hiányoznak a tapasztalt fejlesztők egy új nyelvhez
Egy új nyelv esetében természetesen sokkal kisebb lesz a tapasztalt fejlesztők köre. Ez minden közép- vagy nagyvállalat számára nagy probléma. Minél több fejlesztő áll egy cég rendelkezésére, annál jobb.
Továbbá, ha a cégnek van tapasztalata a C fejlesztők toborzásában, nem tudják, hogyan kell toborozni erre az új nyelvre.
Végül, ha érdekel, hogy többet tudjon meg róla, keresse fel a részletek a következő linken.