Microsoft macht jetzt Rust im Kernel.

Bei Linux war (und bin) ich nicht so der Fan von Rust im Kernel. Der Grund dafür ist vorrangig, dass Rust zwar eine Systemsprache ist, aber nicht für solche Szenarien entwickelt wurde. Ein Beispiel dafür sind hidden allocations, die man nicht ausschließen kann. Man kann zwar bei vielen Dingen mittlerweile einen Allocator mit angeben, das war aber eher so ein afterthought. Bei Linux lösen sie das (soweit ich weiß) so, dass sie die C-Datenstrukturen im Kernel Wrappen, man also z. B. der Linked-List, die man bei Linux seit jeher verwendet, ein Rust-Interface geben. Das lässt mich vermuten, dass man Rust im Linux-Kernel nicht so schreiben wird, wie man Rust im Userland schreibt und man lediglich die Compilerfeatures wie den Borrow-Checker sinnvoll verwenden kann. Sowas wie Vec<T> habe ich da bisher nicht gesehen. Vielleicht irre ich mich da aber auch!

Rust wurde als C++-Ersatz konzipiert, nicht als C-Ersatz. Als C-Ersatz hingegen wurde z. B. Zig konzipiert. Das ist einer der Gründe, warum ich Zig eher im Linux-Kernel sehe, als Rust. Zig ist leider noch weit weg davon, stabil zu sein.

Bei Windows hingegen scheint das ne andere Story zu sein. Dort verwenden sie schon länger C++. Sie werden damit schon lange einen Weg gefunden haben, mit den Allocations umzugehen und damit einfacher Rust zu adoptieren.
Deshalb überrascht mich es auch nicht, dass sie es hinbekommen, die Rust-spezifischen APIs im Kernel zu verwenden. Als Beispiel führen sie Vec und Result an. Während Rust-Menschen zu OOM-Fehlern gesagt haben “installier doch einen globalen handler für OOM-Fehler” (das ist ja jetzt auch nicht die Spitze des Software-Engineering), hat MS die andere Route gewählt und die Standard-Rust-APIs um mehr try_ ergänzt.

Das Pilotprojekt war scheinbar ein GDI-Rewrite. Das freut mich besonders, denn ich hab schon so einige Probleme mit GDI gehabt. Hat bestimmt auch Spaß gemacht, Code aus den 80ern wegzuwerfen.