Karstās debates par Rust iekļaušanu Linux kodolā hakeru kopienā ir notikušas jau labu laiku. Lielākā daļa no mums atzīst gan ažiotāžu, gan vilcināšanās par to. Līdz šim lielākā daļa diskusiju ir vērstas uz tūlītējiem jautājumiem, piemēram, Rust drošības priekšrocībām un problēmām, kas saistītas ar tās integrēšanu esošajā C balstītajā ekosistēmā. Tagad, kad Linuss Torvalds ir pieņēmis šo ideju , Rust jau ir sācis savu ceļu uz mūsu mīļās operētājsistēmas pirmkodu.
Tādējādi patiesais jautājums nav par to, vai izmantot Rust Linux kodolā, bet gan kā . Galu galā Rust nav tikai vēl viena programmēšanas valoda; tā ir arī pilnvērtīga dizaina filozofija. Tas nav C jauninājums ar mazāku atmiņas bojājumu kļūdu skaitu, bet gan koda rakstīšanas sistēma, kas uzspiež stingrus noteikumus, tādējādi novēršot daudzas iespējamās kļūdas. Es uzskatu, ka tas ir galvenais aspekts, kas mums jāņem vērā, iegulstot Rust Linux kodolā.
Saskaņā ar pētījumu par organizācijas divkāršību , ļoti liela mēroga projektiem, piemēram, Linux, ir nepārtraukti jāiesaistās divu veidu darbībās, lai tie būtu pielāgojami, atbilstoši un veiksmīgi:
Pētījumi arī liecina, ka uz īstermiņu orientētām ekspluatācijas darbībām ir tendence izstumt ilgtermiņa orientētas izpētes darbības . Tas ir kā vēlme apgūt jaunas prasmes vai strādāt pie netradicionāla projekta, bet tā vietā vienmēr izvirzot prioritāti ikdienas uzdevumiem. Tas pats attiecas uz lieliem projektiem, piemēram, Linux; ja viņi pārāk daudz koncentrējas uz īstermiņa efektivitāti, tie riskē ilgtermiņā novecot. Pasaule nemitīgi mainās, kamēr projekts paliek nemainīgs, padarot tā piedāvājumus arvien neatbilstošākus mainīgajām lietotāju vajadzībām.
No vienas puses, Rust pieņemšana ir ļoti netradicionāls eksperiments, ko var uzskatīt par Linux izpētes darbību. No šī viedokļa Rust iekļaušana ir pamatota. Tomēr, no otras puses, atšķirībā no C — kas aptver visu veidu trakumu un nenoteiktu uzvedību ar atplestām rokām, padarot to par populāru valodu zema līmeņa uzlaušanai, Rustai ir iekšēja birokrātija, kas ievieš noteiktu strukturētu koda rakstīšanas veidu. Savā ziņā Rust darbojas gan kā programmēšanas valoda, gan kā procesu pārvaldības sistēma, līdzīgi tādām metodoloģijām kā Six Sigma. Konkrēts, strukturēts koda rakstīšanas veids noteikti var palīdzēt racionalizēt procesus un uzlabot īstermiņa rezultātus, piemēram, drošības ievainojamības un uzticamības problēmas. Tomēr, tāpat kā citu procesu vadības sistēmu gadījumā , šī stingrība rada riskus arī ilgtermiņa veiklībai un pielāgošanās spējai.
Tāpēc Rust nopelni procesu racionalizācijā un drošāku padarīšanā īpaši izceltos kodola komponentos, kur ilgtermiņa pielāgošanās spēja ir mazāk svarīga. Piemēram, ierīču draiveri mijiedarbojas tieši ar ārējām ieejām un ir augsta riska komponenti atmiņas drošības un uzticamības ziņā. Tādējādi ir jēga tos rakstīt ar Rust. Tām mēdz būt arī salīdzinoši īsāks kalpošanas laiks, jo jaunas ierīces bieži aizstāj vecās. Citiem vārdiem sakot, bažas, ka Rust metodoloģija varētu samazināt izpēti, vai iespēja, ka galu galā mēs varētu vēlēties attālināties no Rustas koda rakstīšanas filozofiju izmaiņu dēļ, kļūst mazāk nozīmīgas. Ja ierīces draiveris ir izstrādāts ar Rust, tas parasti ir drošāks un uzticamāks, un citi komponenti netiek veidoti, pamatojoties uz šo kodu. Tā rezultātā dažu desmitgažu laikā tas nevienam nepiespiež kādu konkrētu koda rakstīšanas veidu.
Turpretim kodola galvenajiem komponentiem, piemēram, plānotājam, ir jāpaliek pielāgojamiem, lai pielāgotos nākotnes izaicinājumiem un jaunām paradigmām. Rūsas izmantošana šajos apgabalos var radīt stingrību, kas kavē izpēti un noved pie novecošanās. Padomājiet par to šādi: Nākotnes kodam ir jābalstās uz komponentiem, kas tiek veidoti šodien, un, kad galu galā cita programmatūras rakstīšanas filozofija nākotnē izrādīsies izdevīgāka, ļoti elastīgo C kodu parasti var pakāpeniski mainīt, līdz tas tiek pārveidots par jauno pieeju (pakāpeniska stratēģiskā atjaunošana). Turpretim Rust uzstāj uz savu koda rakstīšanas veidu, tāpēc tas, visticamāk, radīs dilemmu turpināt attīstīties, izmantojot veco pieeju, salīdzinot ar tā rakstīšanu no nulles. Ņemot vērā to, ka bezmaksas programmatūrai vienmēr ir bijušas grūtības atrast pietiekamu skaitu kvalificētu un regulāru brīvprātīgo, kā arī pietiekamu regulāru finansējuma apjomu, pakāpeniski uzlabojumi vienmēr ir daudz vieglāk nekā pieņemt lēmumu veikt lielu projektu, piemēram, izmest komponentu un rakstīt no nulles. Tāpēc jebkura valoda, kas uzstāj uz noteiktu koda rakstīšanas veidu, var kļūt par saistībām nākotnē, liekot Linux turpināt vecāku koda rakstīšanas veidu un zaudējot savu progresīvāko pozīciju.
Īsi sakot, es ierosinu hibrīda stratēģiju, kurā Rust vairāk izmanto īstermiņa komponentiem, kur drošība ir ļoti svarīga, savukārt C — visvieglākā valoda, kas nav specifiska aparatūrai — ir prioritāte ilgtermiņa komponentiem, lai saglabātu elastību nākotnes paradigmām un pieejām.