3 ms·

I think it’s worthwhile for researchers/hobbyists to develop toy kernels in Zig. Using it for Linux is just plain irresponsible. The bottom line is that, unlike

I think it’s worthwhile for researchers/hobbyists to develop toy kernels in Zig. Using it for Linux is just plain irresponsible. The bottom line is that, unlike Rust, Zig is unstable and unsuitable for production software. If real money or human lives depend on the software (as is the case with Linux) the choice of programming language should be somewhat conservative. It is worth looking at all the serious bugs in deficiencies in the upcoming 0.8 milestone: https://github.com/ziglang/zig/milestone/10 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.

ncmncm 5y ago
That is a compelling argument for no more C in Linux. But a compelling argument and $5 gets you a cuppa. 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.
- est31 5y ago
  > 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 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.
  - jorangreef 5y ago
    Zig's approach to safety is quite different to Rust's. As someone who has done a fair amount of security work, I actually prefer Zig's design decisions. I believe they make for safer, simpler, more readable programs. Attackers love complex systems, and the majority of low hanging fruit out there is not for lack of memory safety. 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.
    - est31 5y ago
      Note that Rust's strong type system with algebraic types as well as rich set of lints catches more bugs than just memory safety ones. 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/ 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.
      - jorangreef 5y ago
        How about checked arithmetic? I'm familiar with the post you linked. Again, as someone who has done security work, I was fascinated by footnote 3 under the table: "not by default, but available via compiler setting or by linting against unchecked arithmetic". 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.

ncmncm 5y ago

That is a compelling argument for no more C in Linux. But a compelling argument and $5 gets you a cuppa. 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.

est31 5y ago
> 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 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.
- jorangreef 5y ago
  Zig's approach to safety is quite different to Rust's. As someone who has done a fair amount of security work, I actually prefer Zig's design decisions. I believe they make for safer, simpler, more readable programs. Attackers love complex systems, and the majority of low hanging fruit out there is not for lack of memory safety. 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.
  - est31 5y ago
    Note that Rust's strong type system with algebraic types as well as rich set of lints catches more bugs than just memory safety ones. 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/ 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.
    - jorangreef 5y ago
      How about checked arithmetic? I'm familiar with the post you linked. Again, as someone who has done security work, I was fascinated by footnote 3 under the table: "not by default, but available via compiler setting or by linting against unchecked arithmetic". 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.