Comment by rednafi
10 months ago
There will be a similar drama when Zig reaches 1.0. There will be a bunch of Ziggers trying to get it into the kernal. The Rust fad is already slowing down. Maybe it's a good idea to wait 10-15 years before trying to rewrite the universe in a "memory safe" language and pushing that upstream.
Zig brings developer velocity benefits over C, but developer velocity is not the reason R4L exists. Until Zig has an easily segmented part that is memory safe, there is no demand for its potential benefits in Linux. Memory safety is the only reason a new language was considered within Linux.
Zig is at least better impedance matched to C. Procedural and relatively small conceptually. Simple interop. Rust feels closer to C++ than C.
Zig fixes many of my woes with C. Compilation time is better than Rust’s, and there’s no borrow checker. I also find the Zig community more pleasant than Rust’s.
The Rust ecosystem never clicked for me the way Go or Zig did. But I work with I/O-heavy distributed systems, where Go outshines Rust in most cases, so that’s what I use the most.
Systems programming is a different beast, though, and I’m glad the push for rewriting everything in Rust has lost its initial momentum while Zig is emerging as a strong contender. Even then, I wouldn’t want Ziggers to start pushing things upstream into the kernel anytime soon.
Maybe, I think it's more likely that a Zig soft fork would first replace the kernel build system and then, with unit tests, piece by piece port the whole beautiful thing. Zig is on a strong path to compile and interact with C better than existing C compilers.
I like Zig a lot over Rust but I guess people should give it a while (10y) before attempting something like that. Zig isn’t even 1.0 yet and it’s not going to be for at least 2 more years.
In 10 years C compiler may include the benefits of a borrow checker but in a more flexible manner.
Or C can get cleaned up and become something like Zig. I would rather read messy C or Zig code over Rust in any day.