3 ms·

Too bad that Ziglang is still too immature at this point. It seems to be more in spirit with C and UNIX - simple yet powerful, while avoiding most of C's footgu

Too bad that Ziglang is still too immature at this point. It seems to be more in spirit with C and UNIX - simple yet powerful, while avoiding most of C's footguns. Would have been interesting to see what Linus thinks of it. Adding a 3rd language would be madness, Rust is already complex enough - so that window of opportunity will be closed.

roca 5y ago
Rust can prevent use-after-free bugs and data races, which is very useful for the kernel.
phendrenad2 5y ago
You can still use Zig for out-of-kernel modules, which unfortunately are a concept that doesn't get much love.
moltonel3x 5y ago
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.
unrealhoang 5y ago
I think the reverse is true, with Rust explore the new multi-language codebase and tooling (LLVM) for Linux, it would be easier for Zig to be another supported language for the kernel.
- MrBuddyCasino 5y ago
  Every language added means less people are able to review patches, and it means a higher barrier to participation. Do you think there should be a limit to the number of supported languages or not? If yes, what would that number be?
  - unrealhoang 5y ago
    With the codebase as big and complex as Linux, you don't have to know everything to be able to contribute. It will be different module being implemented in different language, and more language supported is more people can contribute to the codebase (people who has been put off by C). Furthermore, for a language to be supported, it must have enough infrastructure (tooling, people, convention...) to support that language first, so people to review patches shouldn't be a problem. Obviously, language should not be added willy-nilly, it must prove that it can solve some problem that the current set of languages can not solve efficiently, and base on that merit, it will choose to write/rewrite the modules that have the most of those problems first. TL,DR: a decentralized codebase.

roca 5y ago

Rust can prevent use-after-free bugs and data races, which is very useful for the kernel.

phendrenad2 5y ago

You can still use Zig for out-of-kernel modules, which unfortunately are a concept that doesn't get much love.

moltonel3x 5y ago

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.

unrealhoang 5y ago

I think the reverse is true, with Rust explore the new multi-language codebase and tooling (LLVM) for Linux, it would be easier for Zig to be another supported language for the kernel.

MrBuddyCasino 5y ago
Every language added means less people are able to review patches, and it means a higher barrier to participation. Do you think there should be a limit to the number of supported languages or not? If yes, what would that number be?
- unrealhoang 5y ago
  With the codebase as big and complex as Linux, you don't have to know everything to be able to contribute. It will be different module being implemented in different language, and more language supported is more people can contribute to the codebase (people who has been put off by C). Furthermore, for a language to be supported, it must have enough infrastructure (tooling, people, convention...) to support that language first, so people to review patches shouldn't be a problem. Obviously, language should not be added willy-nilly, it must prove that it can solve some problem that the current set of languages can not solve efficiently, and base on that merit, it will choose to write/rewrite the modules that have the most of those problems first. TL,DR: a decentralized codebase.