moltonel3x

Zig is a really nice language, but it doesn't go as far as Rust in the correctness department, which is what's motivating Rust adoption in Linux (other Rust aspects being merely nice-to-haves). It's not clear that Zig would bring sufficient gains to overcome the cost of adding a language, even if it was as mature as Rust.

Not going to be merged into a release branch yet, this is more of a "status update, give it a try" posting. We'll certainly see a few more of those before we get a proper Rust-enabled Linux release.

Being a smaller simpler language doesn't make it easier to read or write. Go is an even "simpler" language than C, but you quickly suffer from boilerplate-blindness when reviewing it. Being able to write good abstractions can make a huge difference. Having lifetimes, or the use of the semantically-correct integer type checked by the compiler reduces the cognitive load on the writer and reviewer.

> If you are going to develop kernel because it uses cool new language but you would not if it was still C, you are probably not the right person.

You are taking this the wrong way around. It's not about people contributing to $PROJECT because it uses $COOL_TECH, it's about people being turned off from contributing to $PROJECT because of $MEH_TECH.

If Linux was written entirely in assembly, we'd be having the same argument about the introduction of C.

I actually find Rust easier to refactor Rust code than my other $DAYJOB languages, thanks to its strict type system, its informative function signatures, and its syntax. These are ingredients that make Rust programming "fearless".

I don't have enough Ada experience to compare, but Rust is IMHO much easier and less complex than C++. Rust is renowned to have a steep initial learning curve, but that curve doesn't climb nearly as high as C++'s.

async/await doesn't have to be painful: Slap a `#[tokio::main]` in front of your `main()` and a `.await` after your heim functions. Done.

The C and C++ specs are full of UB though, more like a "minimum common denominator" for compiler devs than a strict spec that users can rely on. It's way too easy to write spec-abiding code that behaves differently with different compilers/architectures/optimizations.

Specs are definitely a good thing to have, but often they're just brandished as a bullet point without looking at the details: how good is the spec, what does it add over the existing tests/CI/RFCs/proofs, etc.

Looking forward to the day when gcc gains a C++ frontend written in Rust, to enable bootstraping gcc from a rust compiler :)

This isn't just anecdotal usage, we've seen plenty of Rust blog posts, job offers and opensource releases from these companies.