Quale livello di programmazione di basso livello può essere raggiunto con le lingue come Go?

Non sono sicuro di andare, ma D specifica chiaramente quali costrutti possono accedere al garbage collector ( alla fine qui ; In realtà penso di aver visto una spiegazione più dettagliata sul sito, ma non riesco a trovarla rapidamente). Quindi puoi scegliere dove gc può e non può operare.

1. Viene eseguito direttamente nella memoria limitata, senza latenza significa (difficile) in tempo reale. Il che significa che non puoi usare nemmeno le eccezioni di C ++ nuove ed eliminare, né C ++ né molte altre caratteristiche di C + + o C. Il sottoinsieme D che puoi usare in questi casi è ben definito e grazie a custom new / delete anche abbastanza capaci.

   La maggior parte dei kernel del sistema operativo non eseguono alcuna operazione in tempo reale e eseguono soft in tempo reale ("con una latenza sufficientemente rara") solo nelle routine di servizio di interrupt. Molte parti di un sistema operativo potrebbero facilmente utilizzare un collettore di stile mark & sweep ed essere più performanti dei sistemi attuali che solitamente fanno riferimento al conteggio. Richiederebbe un collettore parallelo a due fasi accuratamente elaborato, ma è fattibile.

2. Poiché gira su una base di software, ma deve ancora funzionare bene , mentre il garbage collector implica sempre un uso di memoria un po 'più alto, le prestazioni sono solitamente comparabili e spesso superiori a programmi di memoria espliciti. Questo perché le singole operazioni sotto garbage collector sono in genere più semplici e perché i pattern di allocazione tendono a migliorare l'utilizzo della cache.

   In combinazione con il fatto che, nonostante tutte le ricerche fatte su allocatori di memoria decenti, la maggior parte delle librerie C standard in natura hanno ancora un malloc che fa schifo, non c'è alcun handicap per Go o D qui.

So che questa risposta è in ritardo per la festa, ma ne ho ancora un po 'da aggiungere.

Go è significativamente più alto di C / C ++ / D: non ha gestione manuale della memoria, ha un ambiente di runtime significativo e utilizza più memoria in generale. Non vorrai scrivere un kernel in Go perché dovresti prima trasferire il (grande) runtime nello spazio del kernel. Se lo facessi, probabilmente incontrerai problemi di prestazioni difficili da risolvere poiché Go non è così intuitivo come C.

Credo che D sia inteso principalmente come sostituto di C ++. Il ruolo di C ++ è stato in gran parte come un linguaggio di programmazione di sistemi / librerie di livello utente. In parte, questo è dovuto al fatto che C era già dominante nel kernel quando C ++ ha iniziato a diventare popolare. L'altra parte è che il runtime di C ++, per lo più limitato all'allocatore di memoria, deve essere portato anche al kernel. Ci sono certamente stati molti progetti C ++ nello spazio del kernel, ma non è dominante lì.

D si è posizionato per essere un eccellente linguaggio di scrittura in biblioteca, e ha limitato la sua utilità nel kernel richiedendo un runtime più ampio del C ++ (o certamente di C). Se lo sminuisci un po '(senza GC, senza librerie standard, senza variabili thread-scope, alcuni significativi segmenti di codice non sicuri, ...) puoi farlo girare nel kernel easily , ma poi ti stai liberando di molti dei suoi miglioramenti rispetto al C ++.

Tuttavia, le sue caratteristiche prestazionali e la capacità di scrivere codice di basso livello sono eccellenti e (più o meno) corrispondono a quelle di C o C ++. Lo raccomando in particolare per i progetti a livello di utente, ma ci sono alcune grandi cose che può essere aggiunto a un progetto del kernel (anche se alcune delle sue funzionalità più interessanti non sono facilmente accessibili lì).