I wonder if Zig [1] would be a better fit than Rust for the Linux Kernel. I haven't touched systems programming for a decade, but looking from the outside, it seems like the author put even more effort towards C ABI compatibility than the Rust team.
It is worth looking at all the serious bugs in deficiencies in the upcoming 0.8 milestone: https://github.com/ziglang/zig/milestone/10
This is not a criticism of Zig, nor is it an insinuation that Zig is unable to write correct software. It is a reflection of that fact that compilers are very complex.
Any argument that Rust, by contrast, would be OK in the kernel applies at least as strongly to C++, because C++ can read kernel C headers, where Rust will need hand-maintained equivalents. (Some automation is possible, but not enough.) The FUD Linus flings about C++ applies equally to Rust. (Anybody who says Rust is less complicated does not know Rust well at all.)
But argument validity is not what carries the day: bad arguments tend to fail, but good arguments get pot luck. Ultimately, it comes down to biases of those with power to decide: C seems to them like a familiar quantity (full of risks, but favored risks), while Rust happens to be hot just now.
In three years' time, Rust could very well not be so hot, and a new new thing might take over its social role. Zig could conceivably be that thing. (Zig isn't "safe", by Rust's definition, but by then something else may be more important; anyway the lack of safety does not disqualify C.) The new hotness will necessarily already exist today, to be mature enough to consider then, but not necessarily one that immediately comes to mind. Being different from Rust could be, by then, among the new hotness's attractive qualities, much as percieved differences from C++ boost Rust in some milieus.
Zig is totally different from Rust. For starters, it does not have a safe subset of the language that prevents an entire class of bugs. It's slightly nicer C. There are plenty of languages like that.
> [Zig is a] slightly nicer C. There are plenty of languages like that.
Are there “plenty of [actively supported] languages like that?” The design space of relatively simple, typesafe, imperative native programs strikes me as rather unexplored since the early 90s. At least I can’t think of many languages I would consider a nicer alternative to C - indeed actual C alternatives like Pascal and Fortran are arguably less nice. Maybe this is my ignorance.
There are various languages “between” C and C++ in terms of abstraction and complexity, and the space of “somewhat C-like” languages is heavily explored (D, Java, C#, Objective-C, and in a different sense Ada or Swift). There are plenty of alternatives to C++. But Zig is one of the only ones that’s not dramatically more complex than ISO C.
Happy to be corrected if I am missing something obvious (I mostly do functional programming).
Also, the more familiar one is with a subject, the less one tends to conflate it with "plenty" of others. Zig is a completely different language to C (while also targeting the same systems space where you would need "unsafe" Rust to get anything done). In fact, it's hard to find too many languages that come close to Zig's comptime, plus the entire array of safety features offered by Zig. Your argument is a weak strawman at best.
Zig might have some safety features, but it's dwarfed by what Rust has to offer: https://scattered-thoughts.net/writing/how-safe-is-zig/
More importantly, you can cause exploitable crashes in Zig programs while in Rust you need unsafe for it (at some point in the program).
And yes, each Rust codebase has unsafe somewhere, but there are quite many codebases that don't have a single line and instead use dependencies that encapsulate the unsafe in a safe to use API.
Would you say also that Rust's macros offer a stronger type system than Zig's comptime?
There is this misconception that Rust will make systems secure simply "because memory safety". But this overlooks the most foundational point of systems safety: simplicity. Most failures or exploits (two sides of the same coin really) originate through excessive dimensionality, a point where Rust's complexity unfortunately dwarfs Zig's.
The kernel project distributes several userspace utilities and new ones of those might be worth writing in Zig.
However, each has their place. One man passion projects should not be used in anything mission critical. They totally should be used for fun, enjoyment and inspiration, and they may potentially grow to industry scale.
Zig is newer than Rust, but the Zig Software Foundation was in fact founded before the Rust Foundation, and already employs several core members. For example, Jakub Konka who resigned from Microsoft to work for the ZSF (https://ziglang.org/news/jakub-konka-hired-full-time/), and whose linker was the first to enable cross-compilation to Apple Silicon, and is already making Rust's cross-compilation just work (https://news.ycombinator.com/item?id=27245369).
Inspiring how such a young language can already be so far ahead when it comes to something as vital as the compile chain.
It's not funny if you understand the relative priorities of the two teams. Rust tends to prioritize working with the system, so all of our default configurations use the system linker. Zig doesn't have the same constraints.
This feature is awesome, and I would love to see it in Rust as well, but like, it's not surprising.
No, Zig absolutely has an awesome compiler. It's not "a toy" or a "one man passion project" and it's condescending to reduce it to those terms, as if it is not also somehow "industrial scale".
To be fair, your comment would also be better served without the insinuation of "just trying to score internet points".
I've made the edit. Thanks for the tip. I've enjoyed and learned from this exchange with you.
Individual insight is often much better than a design by committee, but a language needs a quite robust ecosystem of support from industry bodies at some point to become a viable tool for generic industry scale development.
https://github.com/graydon/rust-prehistory/graphs/contributo...
After the initial commit in the "group" repo, development of the language has switched to a team instead of a single person, with the introduction of additional contributors. This holds even if you only look at the pre-1.0 days which established the core concepts of the Rust language as it stands today (the original language when the team started to work on it was a bit different to 1.0).
https://github.com/rust-lang/rust/graphs/contributors?from=2...
The work since 1.0 can be classified as a massive refinement project, which also does not have a single leader. Zig on the other hand does have a single main contributor/maintainer/creator:
https://github.com/ziglang/zig/graphs/contributors?from=2015...
hostapd is maintained by a single human. They are responsible for about 69% of all commits in the git repo, 55% if you look at the last year. It's still the most widely deployed WiFi implementation of the world. https://www.openhub.net/p/hostapd/contributors/summary
This is not an argument against Zig or that it would not become an industrial scale tool. It just does not feel "lindyproof" yet for real work.