[weebull]

I personally feel the Zig is a much better fit to the kernel. It's C interoperability is far better than Rust's, it has a lower barrier to entry for existing C devs and it doesn't have the constraints the Rust does. All whilst still bringing a lot of the advantages.

...to the extent I could see it pushing Rust out of the kernel in the long run. Rust feels like a sledgehammer to me where the kernel is concerned.

It's problem right now is that it's not stable enough. Language changes still happen, so it's the wrong time to try.

[agentultra]

From a safety perspective there isn't a huge benefit to choosing Zig over C with the caveat, as others have pointed out, that you need to enable more tooling in C to get to a comparable level. You should be using -Wall and -fsanitize=address among others in your debug builds.

You do get some creature comforts like slices (fat pointers) and defer (goto replacement). But you also get forced to write a lot of explicit conversions (I personally think this is a good thing).

The C interop is good but the compiler is doing a lot of work under the hood for you to make it happen. And if you export Zig code to C... well you're restricted by the ABI so you end up writing C-in-Zig which you may as well be writing C.

It might be an easier fit than Rust in terms of ergonomics for C developers, no doubt there.

But I think long-term things like the borrow checker could still prove useful for kernel code. Currently you have to specify invariants like that in a separate language from C, if at all, and it's difficult to verify. Bringing that into a language whose compiler can check it for you is very powerful. I wouldn't discount it.

[brokencode]

I’m not so sure. The big selling point for Rust is making memory management safe without significant overhead.

Zig, for all its ergonomic benefits, doesn’t make memory management safe like Rust does.

I kind of doubt the Linux maintainers would want to introduce a third language to the codebase.

And it seems unlikely they’d go through all the effort of porting safer Rust code into less safe Zig code just for ergonomics.

[weebull]

> Zig, for all its ergonomic benefits, doesn’t make memory management safe like Rust does.

Not like Rust does, no, but that's the point. It brings both non-nullable pointers and bounded pointers (slices). They solve a lot of problem by themselves. Tracking allocations is still a manual process, but with `defer` semantics there are many fewer foot guns.

> I kind of doubt the Linux maintainers would want to introduce a third language to the codebase.

The jump from 2 to 3 is smaller than the jump from 1 to 2, but I generally agree.

[eru]

> I kind of doubt the Linux maintainers would want to introduce a third language to the codebase.

That was where my argument was supposed to go. Especially a third language whose benefits over C are close enough to Rust's benefits over C.

I can picture an alternate universe where we'd have C and Zig in the kernel, then it would be really hard to argue for Rust inclusion.

(However, to be fair, the Linux kernel has more than C and Rust, depending on how you count, there are quite a few more languages used in various roles.)