rfcs VS Rust-for-Linux

Rust had that, but decided it wasn’t a good enough fit. Which was the motivation to keep exploring and land on the current async implementation which scales from embedded to servers with minimal overhead.

History:

* This RFC proposes to remove the runtime system that is currently part of the standard library, which currently allows the standard library to support both native and green threading.*

https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...

I found 14 real-world ADR examples — from Kubernetes KEPs to Spotify's ADR practice to Rust RFCs. Reading how top engineering teams document decisions taught me more than any course.

> It may just be a matter of perspective -- if you don't count rust pre 1.0, then yeah it "never" involved backtrace.

Yes. I'm only counting what has been part of the stable API since Rust 1.0.

I agree that following the stabilization path and future direction of a feature can be difficult.

> Because if the only purpose was error chains, it could have been in core on the day of rust 1.0, as it is today. I think what actually happened is `fn backtrace(&self) -> Option` was removed shortly before 1.0, but there were some misgivings about that and some on the core team wanted to bring that back eventually. And that was the main reason that it could not move to core, because that would make it a breaking change to bring `fn backtrace` back. At least that's what I remember from PRs I followed at the time. (There may have been other reasons besides this though?)

The only purpose is not chaining. Backtraces were definitely a desirable part of it! But we wanted to move `Error` to `core` and having backtraces be tightly coupled to `Error` would not allow that. As far as I remember, that was always the tension. To my memory, it wasn't until Jane wrote down the "generic member access" direction[1] for the `Error` trait that this tension was finally broken.

[1]: https://github.com/rust-lang/rfcs/pull/2895

It's being worked on! https://github.com/rust-lang/rfcs/pull/3470

There’s a reason tools like GitHub RFC templates exist: structure matters. AI is great at scaffolding, but you need to provide the judgment and the trade-offs.

Yes of course, although, as I said in a sibling comment, it's a bit convoluted as an example. The fundamental problem is that the xor mutable and shared reference rule gets in your way when you access separate fields through &self and &mut self even if the borrows are non-overlapping.

There has been discussion to solve this particular problem[0].

0: https://github.com/rust-lang/rfcs/issues/1215

RFC 3201 – Async Drop – Talks about the idea of making Drop support async. Not in Rust yet, but might be in the future.

You're welcome.

> Any concerns of the same kind of thing?

Here's the canonical list: https://github.com/Rust-for-Linux/linux/issues/2

There's a lot, and I don't know the status of many of them, personally. But I don't see anything there that I know is not gonna work out, like for example, they aren't using specialization. Most of it feels like very nuts and bolts codegen options and similar things.

That said, back in August, the Rust Project announced their goals for the second half of this year: https://blog.rust-lang.org/2024/08/12/Project-goals.html

They say that they're committed to getting this stuff done, and in particular: https://rust-lang.github.io/rust-project-goals/2024h2/rfl_st...

> Closing these issues gets us within striking distance of being able to build the RFL codebase on stable Rust.

So, things sound good, in my mind.

The goal of rust for linux isn't to wholesale translate linux into rust, but simply to be able to write pieces of linux (largely new ones) in rust. I think it's very unlikely anyone (including google) will take on a wholesale translation anytime soon. That said

> It's unlikely that Google has much sway here

Google has helped fund the rust for linux project pretty much from the start [1], they're one of three organizations mentioned on the homepage due to their sponorship [2]. They're actively involved in it, and have already ported their android "binder" driver into it with the intent to ship it in android. This strikes me as a very weird take.

[1] https://www.memorysafety.org/blog/supporting-miguel-ojeda-ru...

[2] https://rust-for-linux.com/

Rust is backwards compatible when you stick to stable features, but the kernel uses unstable features that can and do incur breaking changes.

https://github.com/Rust-for-Linux/linux/issues/2

> How would this work?

Don't know exactly what you're asking.

> And why would it be a better idea?

Poorly written device drivers are a significant attack vector. It's one of the reasons Linux is now exploring using Rust for its own device drivers.[0] You may be asking -- why Rust and not some other language? Rust has many of the performance and interoperability advantages of C and C++, but as noted, makes certain classes of memory safety issues impossible. Rust also has significant mindshare among systems programming communities.

[0]: https://rust-for-linux.com