Ein Blog

Interessanter Post: Why asynchronous Rust doesn’t work

When Rust hurts

Die Leute bei Rust wollen das Coloring-Problem lösen. Den Artikel dazu hatte ich hier auch schon.

Der Versuch: Sagen, dass eine Funktion agnostisch bzw. “generisch bezüglich ihrer Asynchronizität” ist. Da hört es aber nicht auf, sie wollen das auch über const generisch machen. Der Plan ist sogar, das in Zukunft auch für andere Keywords zu machen.

Das hier ist der erste Vorschlag: Keyword Generics Progress Report: February 2023

Money quote:

trait ?const ?async Read {
    ?const ?async fn read(&mut self, buf: &mut [u8]) -> Result<usize>;
    ?const ?async fn read_to_string(&mut self, buf: &mut String) -> Result<usize> { .. }
}

/// Read from a reader into a string.
?const ?async fn read_to_string(reader: &mut impl ?const ?async Read) -> io::Result<String> {
    let mut string = String::new();
    reader.read_to_string(&mut string).await?;
    Ok(string)
}

Das ist ein Read-Trait, bei dem die read-Funktion sowohl async als auch const sein kann. Primeagen (ein Rust-Enthusiast) ist nicht so begeistert. Wirt auf mich jetzt auch erstmal ziemlich verbose und bei einer Sprache, die bewusst keine Keywords mit mehr als 5 Buchstaben nimmt, fehl am Platz. Das haben sie aber offenbar auch selbst erkannt.

Zig möchte Funktionen auf diese Art farbenblind (manchmal auch farblos genannt) machen: What is Zig’s “Colorblind” Async/Await?

Hoffen wir mal, dass Rust nicht den Haskell-Tod der 1000 Abstraktionen stirbt.

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.

Ein bisschen Rust-Gossip: The Rust I Wanted Had No Future

Why am I writing a Rust compiler in C?

Rewriting Rust

The SemVer trick löst ein ABI-Problem bei Rust. Betrifft sicher nicht nur Rust, sondern auch andere Sprachen mit nominellen Typen, die an die Version gebunden sind.

Darüber hinaus frag ich mich, was Rust-Devs immer mit ihren pre-1.0-Releases haben. Es ist einfach total unpraktikabel, wenn man einem Release nicht ansieht, ob es breaking ist. Semver ist dafür da, das zu kennzeichnen. Das hat zwangsweise als Konsequenz, dass man relativ schnell bei Major-Version 600 ist. Das ist auch überhaupt nicht schlimm, aber irgendwie hab ich das Gefühl, dass viele Rust-Library-Devs sich vor der 1.0 fürchten. Stattdessen habe ich jetzt in jedem meiner Rust-Projekte 2/3 Dependencys, die pre-1.0 sind. Da ist das Updaten jedes mal ein Rätselraten.

What would it take to add refinement types to Rust?

Four limitations of Rust’s borrow checker

Unter einem Artikel über Fixed-Integer-Width-Vektoren (hier) stand ein netter Hinweis, den ich hier mal zitiere:

Instead of doing stuff like (word >> bit_offset) & self.mask, in C or C++ I usually write _bextr_u64, or when using modern C# Bmi1.X64.BitFieldExtract. Note however these intrinsics compile into 2 instructions not one, because the CPU instruction takes start/length arguments from lower/higher bytes of a single 16-bit number.

Geht seit Haswell (~2013), cool!

temporal_rs ist eine Rust-Implementierung, die als Backing-API für die JS-Temporal-API gebaut wurde. Benutzt wird sie jetzt scheinbar auch bald in V8, und damit auch in Chrome.

Falls Chrome bisher noch kein Rust hatte (eine Sprache, die von Mozilla für Firefox entwickelt wurde), haben sie es dann spätestens jetzt. Und das noch vor Carbon — eine Sprache, die Google extra für Chrome baut.