Nuovi linguaggi per il Kernel Linux: dopo Rust è giunto il momento di C++?

Negli ultimi mesi abbiamo avuto modo di discutere piuttosto spesso del C++, il linguaggio ideato a inizio anni ottanta per fornire il C del supporto alla programmazione ad oggetti. Oggi ne riparleremo, perché Peter Anvin (Kernel hacker di lungo corso), ha resuscitato un post nella KML (la mailing list del Kernel Linux) vecchio di sei anni per dire che, anche se il 2024 non sarà l’anno di Linux nel Desktop, forse sarà quello di C++ nel Kernel.

Ma procediamo con ordine.

Linus e C++ non sono mai andati molto d’accordo: celebre è il suo messaggio nella mailing-list di Git, in cui si lasciava andare definendo C++ un orribile linguaggio. Un’opinione che, nonostante Linus si sia addolcito parecchio, continua a ribadire.

A dispetto di questo, nel 2018 David Howells, un ingegnere di Red Hat, preparò una patch per compilare il Kernel in C++, supportando funzioni inline, la meta-programmazione con i template e (soprattutto!) l’ereditarietà tra classi. Questo lavoro non attirò molte attenzioni fino a qualche giorno fa, quando Anvin ha come descritto fatto quello che in gergo viene chiamato necro-posting.

“Andrew Pinski recently made aware of this thread. I realize it was released on April 1, 2018, and either was a joke or might have been taken as one. However, I think there is validity to it[..]Both C and C++ has had a lot of development since 1999, and C++ has in fact, in my personal opinion, finally “grown up” to be a better C for the kind of embedded programming that an OS kernel epitomizes. [..]C++14 is in my option the “minimum” version that has reasonable metaprogramming support has most of it without the type hell of earlier versions […]However C++20 is really the main game changer in my opinion; […] C++20 adds concepts, which makes it possible to actually get reasonable errors.”

Come vedete, le motivazioni tecniche per utilizzare C++ ci sono e sono parecchio valide: simulare in C concetti come la gestione delle eccezioni o l’ereditarietà è un’impresa e il codice risultante è, di solito, una combinazione di macro e goto di difficile lettura. Inoltre, un altro forte argomento, è che abbiamo diversi compilatori C++ per un gran numero di architetture e questi sono già stati ottimizzati dopo anni di uso e sviluppo (gcc e LLVM su tutti).

Significativo, poi, è quello che dice Anvin riguardo Rust, recentemente aggiunto come linguaggio supportato dal Kernel.

“Now, “why not Rust”? First of all, Rust uses a different (often, in my opinion, gratuitously so) syntax, and not only would all the kernel developers need to become intimately familiar to the level of getting the same kind of “feel” as we have for C, but converting C code to Rust isn’t something that can be done piecemeal, whereas with some cleanups the existing C code can be compiled as C++.
However, I find that I disagree with some of David’s conclusions; in fact I believe David is unnecessarily pessimistic at least given modern C++.

Se avete provato a scrivere qualcosa in Rust ammetterete che c’è del vero in queste parole: i concetti di borrowing, ownership e lifetime sono parte integrante del linguaggio e, benché il compilatore fornisca un’eccellente aiuto per individuare i problemi, bisogna comunque acquisire dimestichezza con queste regole. In C++, al contrario, se si conoscono le basi del C e si ha un background in C# o Java, le uniche richieste per rendere il linguaggio sicuro è ricorrere agli smart-pointer, utilizzare la RAII e prestare molta attenzione a quando si lavora con l’esecuzione parallela.

Inoltre, come già raccontavamo qui, C++ è lungi dal morire e presto vedremo una nuova release.

Vedremo come andrà questo nuovo tentativo, soprattutto considerando come gli ultimi anni abbiano visto l’apertura dello sviluppo del Kernel agli standard C99 e,ovviamente, a Rust. E voi, cosa ne pensate? Il fatto che il Kernel possa diventare multi-linguaggio sarà un’opportunità o una fonte di caos?