Retiring from the Rust for Linux Project – Wedson Almeida Filho

That seems incorrect. If I am writing software which interacts with a component, then I need to be able to read it to understand what it’s doing. So if a software system includes Rust, then developers of the system will need to at least be able to read it.

That’s not saying anything bad about Rust, at all: it’s just a property of developing in a shared codebase.

Full disclosure: I dislike C but can read it, and I cannot read Rust. Rust sounds like it really is an improvement over C in many ways, but it does seem to suffer from some social problems. As a Lisp user, I can sympathise.

RfL was accepted as an experiment[0], with the understanding that it CAN be ejected again if the evaluation fails. Its mandate was as an opt-in functionality, primarily left for individual maintainers to decide on whether to use and leaf-nodes to use.

It is very likely that this was the very best the RfL project could hope for at that time. Had they pushed for first-class citizenship, other contributors would, sensing the impending impact on their work, likely have revolted and the proposal would have been rejected.

So here we are - this is what the RfL people of the time chose over rejection. No one is changing the game on the RfL devs - if you contribute, you are doing so knowing that this is the official state of affairs.

The problem arises because while individual device drivers and subsystem maintainers indeed can opt-in, bindings provided by RfL impact contributors and maintainers who otherwise wish to avoid using Rust. Namely, if you write Rust bindings for my subsystem and my changes break those bindings, what then ? Am I barred from maintaining my subsystem because you decided to wrap the API for a language I don't know ?

This is not the same as some C code consuming my subsystem breaks on a change, which I can easily fix. This means I now have to read those bindings, understand how they wrap my C API and how their expose API differs from mine (remember: idiomatic (fat) Rust bindings is the goal). I am now on the hook for bindings I had no say in providing or designing?

If you don't understand how this can seem problematic, or how this can seem like maintainers are being forced into learning Rust and maintaining bindings which may well be a non-trivial layer in between the C API and consuming Rust code, then I don't know how to make the problem easier to grasp.

Essentially, it's a very simple instance of "your freedom to swing your hands ends at the point where my face begins" - someone (the RfL binding writers) are swinging their fists about, hitting some maintainers on the nose, and being surprised that said maintainers are angry about that.

[0] - https://docs.kernel.org/rust/

Rust has seen slight interest, but saying that companies like Microsoft are 'moving towards adopting Rust' is just flat out wrong (you realise MS make their own language stack, right? and that it's far more used than Rust?). There's probably more ActionScript 3 in production at MS than Rust.

On the nine year point, your assumption appears to be that Zig is trying to learn from Rust and is behind, but I'm not sure what you're basing this on. Zig isn't trying to do what Rust does, and has no reason to try to relive Rust's growing pains - instead, Zig is trying sand away the rougher edges of C. Zig is not chasing nine years of Rust, it's building on fifty years of C.

Imho, the momentum isn't for moving to Rust, the momentum is for trying to bring memory safety to systems programming (as distinct from most other programming, where GC'd languages are already dominant). Personally, I quite like Rust, but these are early days, and it is not yet clear that Rust will be the language that wins this fight. The history of computing is littered with examples of the slightly less elegant but more practical tool triumphing over the pure but inflexible one.