Most of the languages you’ve mentioned aren’t systems languages, so don’t make being a good language to write an OS in a high priority. More languages might be accepted in the future, but if they are, it’ll be ones that are a natural fit for the problems they’re solving.
I don’t know about Ada, except in jokes about how hard it is to write code that satisfies the compiler, which gives it something in common with Rust. Haskell is a horrible systems language. OCaml might be better. But I don’t think it’s justified to claim Zig isn’t suitably for systems programming, or for writing OSes. Maybe even Odin, but I’m only peripherally aware of it, and don’t know its strengths. Both are young and immature compared to Rust.
What will be hilarious is when, a little down the road, something like Zig will be mature; I’d bet money the loudest gate-keepers objecting to letting it in will be Rustaceans saying some shit like, “Rust already satisfies the safety needs of the kernel; there’s no need to add another language.”
I’m very firmly in the Rust for Linux camp because I am in the “make Linux better” camp, and I don’t see why eventually getting Zig in the kernel would be a problem. If Zig solves problems that C and Rust don’t, by all means, it should be brought in.
However, one of the primary reasons Rust was chosen is that it is memory-safe by default. Zig, on the other hand, has opt-in safety. So unsafe Zig should probably only go in very specific places where C and Rust can’t do the job. And ideally, there would be some rules that require the usage of safe Zig everywhere else.
Ignoring Zig, the language, Zig’s compiler toolchain is hands-down, the best I’ve ever seen, and I think introducing Zig to the kernel by making “Zig-built Linux” a thing, would be a really natural way to get that process going.
I don’t believe, Zig provides much in terms of safety? To my knowledge, it uses manual memory management à la C, just being less horrid in some aspects, like using an option type instead of null pointers.
Most of the languages you’ve mentioned aren’t systems languages, so don’t make being a good language to write an OS in a high priority. More languages might be accepted in the future, but if they are, it’ll be ones that are a natural fit for the problems they’re solving.
I don’t know about Ada, except in jokes about how hard it is to write code that satisfies the compiler, which gives it something in common with Rust. Haskell is a horrible systems language. OCaml might be better. But I don’t think it’s justified to claim Zig isn’t suitably for systems programming, or for writing OSes. Maybe even Odin, but I’m only peripherally aware of it, and don’t know its strengths. Both are young and immature compared to Rust.
What will be hilarious is when, a little down the road, something like Zig will be mature; I’d bet money the loudest gate-keepers objecting to letting it in will be Rustaceans saying some shit like, “Rust already satisfies the safety needs of the kernel; there’s no need to add another language.”
I’m very firmly in the Rust for Linux camp because I am in the “make Linux better” camp, and I don’t see why eventually getting Zig in the kernel would be a problem. If Zig solves problems that C and Rust don’t, by all means, it should be brought in.
However, one of the primary reasons Rust was chosen is that it is memory-safe by default. Zig, on the other hand, has opt-in safety. So unsafe Zig should probably only go in very specific places where C and Rust can’t do the job. And ideally, there would be some rules that require the usage of safe Zig everywhere else.
Ignoring Zig, the language, Zig’s compiler toolchain is hands-down, the best I’ve ever seen, and I think introducing Zig to the kernel by making “Zig-built Linux” a thing, would be a really natural way to get that process going.
I don’t believe, Zig provides much in terms of safety? To my knowledge, it uses manual memory management à la C, just being less horrid in some aspects, like using an option type instead of null pointers.