3 ms·

I think this is missing one major difference in the goals of Zig vs. something like rust. Zig wants to make it possible (and as easy as is practical without ba

I think this is missing one major difference in the goals of Zig vs. something like rust. Zig wants to make it possible (and as easy as is practical without ballooning the language) to make a 100% correct program. That is no panics, no UB, no failed allocation, 100% deterministic behavior. Whereas Rust wants to make 70% or so of bugs that exist elsewhere impossible.

chriskrycho 4y ago
That’s a good goal! A 100% correct program which cannot guarantee a lack of memory safety bugs is not a 100% correct program, though, right?
- suremarc 4y ago
  The absence of a proof of correctness is not a proof of incorrectness, strictly speaking.
- Schroedingersat 4y ago
  Rust still needs unsafe blocks for full generality. Additionally there are many sources of panics that are unavoidable. The memory safety guarantees it makes are also not all bugs. It is equally possible to write a memory safe program in both (although far easier in rust), but impossible to make a panic-safe program in rust without avoiding a large portion of the language. A guarantee of the absence of certain classes of memory bugs is of no use to creating a 100% correct program if it also comes with a guarantee of panic on allocation failure and standard libraries that are full of panics. They are for different things. Rust is for keeping you completely safe from the worst things while you build something big like a web browser where the program doing something you didn't want is the worst failure state, and crashing is a mere inconvenience. It is there to replace C++ Zig is for making it possible to make yourself safe from all bugs if you try hard enough. It is for making small things that you understand fully where crashing is as bad or worse than memory errors like the firmware for a space probe. With the addition of some static analysis tools it could maybe replace or be useful in addition to something like Ada one day, and definitely replace C and some hand coded assembly.
  - pcwalton 4y ago
    How does Zig protect against stack overflow? To make a "100% panic-safe program" you must disallow recursion.
    - csande17 4y ago
      Zig basically does plan to disallow recursion: https://github.com/ziglang/zig/issues/1006#issuecomment-534660820 https://github.com/ziglang/zig/issues/1006#issuecomment-5346... More specifically, it'll force you to allocate memory for your recursive functions on the heap (and thus handle the possible resulting OOM condition).
      - pcwalton 4y ago
        Do you disallow function pointers/closures/virtual methods too, since these can be used to smuggle recursion into the semantics without the compiler being able to statically detect it? You'd have to heap allocate every call to a function pointer, which would be very slow (see how much benefit apps get from PGO which for a long time mostly amounted to optimizing virtual calls).
        csande17 4y ago
        > Do you disallow function pointers/closures/virtual methods too [...] Maybe? Of these features, AFAIK Zig only has function pointers, and they already don't seem to interact very well with other parts of the language. I wouldn't be surprised if they restricted them to comptime-only usage or made "how much stack space does the function need" part of the pointer type or something.
    - Schroedingersat 4y ago
      Disallowing recursion is one possibility (IIRC misra guidelines forbid it). In some circumstances, static proofs are also possible. IIRC it's still an open problem in zig as to what the possible language features will be while keeping this guarantee, but the goal is to be able to have recursion in some circumstances and still provide the possibility of stack-overflow-safety with a performance tradeoff, and to know when you've stepped out of the bounds where that is possible. Here's a thread I'm at least a year out of date on https://github.com/ziglang/zig/issues/1006 https://github.com/ziglang/zig/issues/1006 The general philosophy is to give the programmer tools to know what the consequence of a choice will be as far as that doesn't hamstring them overly. Ie. the compiler can tell you when a stack overflow is possible, and it's up to you to decide what to do about it (or whether it is wrong because you know something it doesn't).
pcwalton 4y ago
This is incorrect in two ways. First, Zig certainly has undefined behavior. Any non-memory-safe language trivially has UB. Second, this implicitly assumes that terminating on OOM is not "correct" behavior, and handling OOM is the "correct" thing to do. But if there's nothing better that the app can do than to terminate on OOM, then terminating is the correct behavior. Many apps fall into this category. There's also the fact that OOM code paths tend not to be well-tested, so empirically aborting on OOM is a safer default.
- skybrian 4y ago
  There's a difference between a language allowing undefined behavior and a particular program written in that language exhibiting undefined behavior. The post you're replying to wasn't claiming that no Zig programs have undefined behavior, but rather that it should be be feasible to avoid it in the programs that you write. (I don't know if that will actually be true, though.)
  - pcwalton 4y ago
    Well, that weaker sense of "correct programs have no UB" is true for Rust as well, then.
    - Schroedingersat 4y ago
      Rust has hidden allocation, no planned static stack analysis or limits on recursion, little to no control over how allocation happens, no ability to guarantee a panic won't happen and thus no ability for the programmer to guarantee eg. essential external resources are cleaned up. The guarantees that zig seeks to enable (this being the key phrase, it does not guarantee them just by its use, nor has the project solved all the problems this entails) the programmer to provide are non-goals of rust. Ie. the projects have completely different goals. The things zig want to provide would make rust unusable if it tried to provide them and vice versa.
      - zozbot234 4y ago
deleted 4y ago
[deleted]

chriskrycho 4y ago

That’s a good goal! A 100% correct program which cannot guarantee a lack of memory safety bugs is not a 100% correct program, though, right?

suremarc 4y ago
The absence of a proof of correctness is not a proof of incorrectness, strictly speaking.
Schroedingersat 4y ago
Rust still needs unsafe blocks for full generality. Additionally there are many sources of panics that are unavoidable. The memory safety guarantees it makes are also not all bugs. It is equally possible to write a memory safe program in both (although far easier in rust), but impossible to make a panic-safe program in rust without avoiding a large portion of the language. A guarantee of the absence of certain classes of memory bugs is of no use to creating a 100% correct program if it also comes with a guarantee of panic on allocation failure and standard libraries that are full of panics. They are for different things. Rust is for keeping you completely safe from the worst things while you build something big like a web browser where the program doing something you didn't want is the worst failure state, and crashing is a mere inconvenience. It is there to replace C++ Zig is for making it possible to make yourself safe from all bugs if you try hard enough. It is for making small things that you understand fully where crashing is as bad or worse than memory errors like the firmware for a space probe. With the addition of some static analysis tools it could maybe replace or be useful in addition to something like Ada one day, and definitely replace C and some hand coded assembly.
- pcwalton 4y ago
  How does Zig protect against stack overflow? To make a "100% panic-safe program" you must disallow recursion.
  - csande17 4y ago
    Zig basically does plan to disallow recursion: https://github.com/ziglang/zig/issues/1006#issuecomment-534660820 https://github.com/ziglang/zig/issues/1006#issuecomment-5346... More specifically, it'll force you to allocate memory for your recursive functions on the heap (and thus handle the possible resulting OOM condition).
    - pcwalton 4y ago
      Do you disallow function pointers/closures/virtual methods too, since these can be used to smuggle recursion into the semantics without the compiler being able to statically detect it? You'd have to heap allocate every call to a function pointer, which would be very slow (see how much benefit apps get from PGO which for a long time mostly amounted to optimizing virtual calls).
      - csande17 4y ago
        > Do you disallow function pointers/closures/virtual methods too [...] Maybe? Of these features, AFAIK Zig only has function pointers, and they already don't seem to interact very well with other parts of the language. I wouldn't be surprised if they restricted them to comptime-only usage or made "how much stack space does the function need" part of the pointer type or something.
  - Schroedingersat 4y ago
    Disallowing recursion is one possibility (IIRC misra guidelines forbid it). In some circumstances, static proofs are also possible. IIRC it's still an open problem in zig as to what the possible language features will be while keeping this guarantee, but the goal is to be able to have recursion in some circumstances and still provide the possibility of stack-overflow-safety with a performance tradeoff, and to know when you've stepped out of the bounds where that is possible. Here's a thread I'm at least a year out of date on https://github.com/ziglang/zig/issues/1006 https://github.com/ziglang/zig/issues/1006 The general philosophy is to give the programmer tools to know what the consequence of a choice will be as far as that doesn't hamstring them overly. Ie. the compiler can tell you when a stack overflow is possible, and it's up to you to decide what to do about it (or whether it is wrong because you know something it doesn't).

pcwalton 4y ago

This is incorrect in two ways. First, Zig certainly has undefined behavior. Any non-memory-safe language trivially has UB. Second, this implicitly assumes that terminating on OOM is not "correct" behavior, and handling OOM is the "correct" thing to do. But if there's nothing better that the app can do than to terminate on OOM, then terminating is the correct behavior. Many apps fall into this category. There's also the fact that OOM code paths tend not to be well-tested, so empirically aborting on OOM is a safer default.

skybrian 4y ago
There's a difference between a language allowing undefined behavior and a particular program written in that language exhibiting undefined behavior. The post you're replying to wasn't claiming that no Zig programs have undefined behavior, but rather that it should be be feasible to avoid it in the programs that you write. (I don't know if that will actually be true, though.)
- pcwalton 4y ago
  Well, that weaker sense of "correct programs have no UB" is true for Rust as well, then.
  - Schroedingersat 4y ago
    Rust has hidden allocation, no planned static stack analysis or limits on recursion, little to no control over how allocation happens, no ability to guarantee a panic won't happen and thus no ability for the programmer to guarantee eg. essential external resources are cleaned up. The guarantees that zig seeks to enable (this being the key phrase, it does not guarantee them just by its use, nor has the project solved all the problems this entails) the programmer to provide are non-goals of rust. Ie. the projects have completely different goals. The things zig want to provide would make rust unusable if it tried to provide them and vice versa.
    - zozbot234 4y ago

deleted 4y ago

[deleted]