Rust in the NetBSD Kernel, and other odd decisions

FreeBSD has as well via ZFS (ZFS channel programs are Lua). I’d love to see a lot more Lua adoption in the FreeBSD kernel and base system.

There are a lot of places where Rust may be necessary for low-level control and so on (for example, there are a lot of places in the kernel where you can’t allocate memory) but a lot more places that don’t have these constraints. I’d love to see more Lua for those.

I think everyone forgets any memory managed language is technically memory safe. Lua being quite fast, you'd only get a speed increase using Rust. But I will say Rust's type system is a major reason to use it too. Are there type systems built on top of Lua? Apparently, yes! https://github.com/andremm/typedlua So all bases are covered.

Has the points regarding platform support, compile times, number of languages and the other points changed in those 8 years? From what I read in that thread, the points made were that adding rust means dropping arches for which Rust currently is not ported or can't even work, compile times would get substantially longer, it would still add a language "everyone" needs to adapt to until it is all rewritten in it so one could drop C. Or that the devs just like C, and I don't think that will change either.

No, but the major blocking point was and will probably always be:

In OpenBSD there is a strict requirement that base builds base.

Is Rust community actually so cutting-edge-oriented that 1.41 would be useless?

When I’m looking for a crate I regularly find crates that haven’t been updated for 5, sometimes 8 years.

Backwards compatibility isn't a problem at the compiler end, it's a problem at the crate end. There were a lot of new idioms introduced after 1.41, both in the language (e.g. const generics were stabilized early in the 1.5x series, let...else clauses a little after that) and in the standard library (OnceCell, OnceLock). So while newer Rust compilers will compile old code just fine, old Rust compilers won't compile a lot of new Rust code.

Rust doesn't have a community[0]; the various communities built around Rust-based projects all have different ideas about how frequently to increase dependency versions, including the compiler.

For use of Rust in the NetBSD kernel it would be up to the NetBSD devs to decide whether they pin to an older rustc version or not. If they pick an old version then they'll find it more difficult to directly use third-party libraries, but that doesn't seem like something they'd be especially bothered by. IMO the obvious solution would be to pick a version supported by mrustc, which would also solve their bootstrap concerns.

The biggest issue with pinning to an old rustc would be correctness fixes, which the rustc developers don't usually backport by more than a few releases. Maybe it'd be enough to test the code with both old and new compilers, and avoid features that tickle bad codegen?

[0] A community is defined by the ability to exclude unwanted individuals. A forum or IRC channel or conference circuit can have a community, but there is no mechanism by which Rust (or any other mainstream programming language) can have a community because it's open to anybody with internet access.

There are some people who are permanently on rust unstable because they need that one latest feature that saves them one line of code every once in a while.

Meanwhile, it's perfectly possible to produce highly complex and robust software on an older Rust version, you just lack a bit of convenience sometimes. But if you're a C/C++ programmer, lack of convenience is already your life so it doesn't matter at all.

However, Rust 1.41 is indeed quite old. I've bumped many of my projects past Rust 1.41 simply because in the meantime, various compiler bugs were fixed (yes, it happens) and powerful features were added. It is true that most of the crates will require a higher version, so if you intend to have a lot of dependencies, it's going to be tough.