5 ms·

The largest difference between Zig and Rust is Zig does not have memory safety. This arguments is more important than all other differences combined. Because wh

The largest difference between Zig and Rust is Zig does not have memory safety. This arguments is more important than all other differences combined. Because when writing very large long living projects, memory safety is the most important issue.

jorangreef 6y ago
Zig does however go a long way towards memory safety, to be fair, and if you wanted to, you could also argue similarly that Rust does not guarantee 100% OOM safety whereas Zig does: https://www.youtube.com/watch?v=Z4oYSByyRak https://www.youtube.com/watch?v=Z4oYSByyRak I would also say that for "very large long lived projects", memory safety is not actually the most important issue, but rather correctness, followed by (in no particular order) safety, performance, explicitness, readability and exhaustive fine-grained error handling, the latter also not found in too many languages besides Zig.
- alserio 6y ago
  Isn't memory safety a subset (and I would argue a necessary requisite) of correctness?
  - jorangreef 6y ago
    Good question. Assuming we both mean "memory safety" as in a guarantee given by the language (e.g. Rust), then no, logically speaking, it can't be a requisite for correctness, and it's not even a subset of correctness. Here's why: If you can write a correct program in a language which does not guarantee memory safety (which we certainly could, for example, simply by not allocating memory at all, or not using pointers etc, or by using runtime checks e.g. to ensure there are no double frees or out of bounds reads/writes), then memory safety is neither a subset of, nor a requisite for correctness. Memory safety is a double-edged sword. It can make correctness easier to achieve. But that also depends on how the language implements memory safety. If this is done by at the expense of a steeper learning curve, then that could in itself be an argument that the language is less likely to lead towards correctness, as opposed to say an almost memory safe language that implements 80% of this guarantee while optimizing for readability, and with a weekend learning curve. Historically, the lack of memory safety has obviously been the cause of too many CVEs. But even CVEs in themselves are more a measure of security than correctness. I would say that exhaustive fine-grained error handling checked by the compiler is probably right up there for writing correct programs.
    - alserio 6y ago
      Thank you for your answer. You can certainly write a memory safe program in a language that doesn't guarantee memory safety. However I still maintain that correctness implies memory safety, at least as a characteristic of the program if not of the language. If your language doesn't help there you should expend more time and effort to achieve that result, and accept higher risk of screwing it up. But I see why you argue that readability correlates with correctness. It's also true that most memory safety issue are really hard to spot, and that may be even more true for 80%-safe language. I really like when the computer does work for me, since as a human I'm way more sloppy.
      - jorangreef 6y ago
        Yes, I fully agree that a correct program can't contain memory bugs, and that we want the compiler to help us. For a systems programming language though, I think Zig hits the sweet spot, and not only with regards to memory safety. Correctness, in this realm, is as much memory safety as: * error safety (making sure that your program correctly handles all system call errors that could possibly occur, without forgetting any, and there are many! The Zig compiler can actually inspect and check this for you, something not many languages do), see https://www.eecg.utoronto.ca/~yuan/papers/failure_analysis_osdi14.pdf https://www.eecg.utoronto.ca/~yuan/papers/failure_analysis_o... for how critical error handling is in distributed systems, * OOM safety (making sure your program can actually handle resource allocation failures without crashing), * explicitness (clear control flow with a minimum of abstractions to make it easy to reason about the code with no hidden surprises, no weird undefined behavior), * and especially as much runtime safety as you can possibly get from the language when you need to write unsafe code (which you will still need to do when writing systems code, even if your language offers memory safety guarantees, see https://andrewkelley.me/post/unsafe-zig-safer-than-unsafe-rust.html https://andrewkelley.me/post/unsafe-zig-safer-than-unsafe-ru...). Here, Zig helps you not only at compile time, but also at runtime (and with varying degrees of granularity as you see fit), something not all systems languages will do. On all these axes, Zig is at least an order of magnitude more likely to lead to a correct program than C, while optimizing for more readable code (even for someone coming from TypeScript) and thus code review, also essential for improving the odds that your code is correct with respect to its requirements.

jorangreef 6y ago

Zig does however go a long way towards memory safety, to be fair, and if you wanted to, you could also argue similarly that Rust does not guarantee 100% OOM safety whereas Zig does: https://www.youtube.com/watch?v=Z4oYSByyRak https://www.youtube.com/watch?v=Z4oYSByyRak I would also say that for "very large long lived projects", memory safety is not actually the most important issue, but rather correctness, followed by (in no particular order) safety, performance, explicitness, readability and exhaustive fine-grained error handling, the latter also not found in too many languages besides Zig.

alserio 6y ago
Isn't memory safety a subset (and I would argue a necessary requisite) of correctness?
- jorangreef 6y ago
  Good question. Assuming we both mean "memory safety" as in a guarantee given by the language (e.g. Rust), then no, logically speaking, it can't be a requisite for correctness, and it's not even a subset of correctness. Here's why: If you can write a correct program in a language which does not guarantee memory safety (which we certainly could, for example, simply by not allocating memory at all, or not using pointers etc, or by using runtime checks e.g. to ensure there are no double frees or out of bounds reads/writes), then memory safety is neither a subset of, nor a requisite for correctness. Memory safety is a double-edged sword. It can make correctness easier to achieve. But that also depends on how the language implements memory safety. If this is done by at the expense of a steeper learning curve, then that could in itself be an argument that the language is less likely to lead towards correctness, as opposed to say an almost memory safe language that implements 80% of this guarantee while optimizing for readability, and with a weekend learning curve. Historically, the lack of memory safety has obviously been the cause of too many CVEs. But even CVEs in themselves are more a measure of security than correctness. I would say that exhaustive fine-grained error handling checked by the compiler is probably right up there for writing correct programs.
  - alserio 6y ago
    Thank you for your answer. You can certainly write a memory safe program in a language that doesn't guarantee memory safety. However I still maintain that correctness implies memory safety, at least as a characteristic of the program if not of the language. If your language doesn't help there you should expend more time and effort to achieve that result, and accept higher risk of screwing it up. But I see why you argue that readability correlates with correctness. It's also true that most memory safety issue are really hard to spot, and that may be even more true for 80%-safe language. I really like when the computer does work for me, since as a human I'm way more sloppy.
    - jorangreef 6y ago
      Yes, I fully agree that a correct program can't contain memory bugs, and that we want the compiler to help us. For a systems programming language though, I think Zig hits the sweet spot, and not only with regards to memory safety. Correctness, in this realm, is as much memory safety as: * error safety (making sure that your program correctly handles all system call errors that could possibly occur, without forgetting any, and there are many! The Zig compiler can actually inspect and check this for you, something not many languages do), see https://www.eecg.utoronto.ca/~yuan/papers/failure_analysis_osdi14.pdf https://www.eecg.utoronto.ca/~yuan/papers/failure_analysis_o... for how critical error handling is in distributed systems, * OOM safety (making sure your program can actually handle resource allocation failures without crashing), * explicitness (clear control flow with a minimum of abstractions to make it easy to reason about the code with no hidden surprises, no weird undefined behavior), * and especially as much runtime safety as you can possibly get from the language when you need to write unsafe code (which you will still need to do when writing systems code, even if your language offers memory safety guarantees, see https://andrewkelley.me/post/unsafe-zig-safer-than-unsafe-rust.html https://andrewkelley.me/post/unsafe-zig-safer-than-unsafe-ru...). Here, Zig helps you not only at compile time, but also at runtime (and with varying degrees of granularity as you see fit), something not all systems languages will do. On all these axes, Zig is at least an order of magnitude more likely to lead to a correct program than C, while optimizing for more readable code (even for someone coming from TypeScript) and thus code review, also essential for improving the odds that your code is correct with respect to its requirements.