6 ms·

Not fighting the borrow checker or making gratuitous copies of data to satisfy the borrow checker. Zig's scope is just to be a better C that's free to add mode

Not fighting the borrow checker or making gratuitous copies of data to satisfy the borrow checker. Zig's scope is just to be a better C that's free to add modern features like optional types, compile time expressions instead of string-macros, source level modules, packages, a more expressive syntax for writing bit-packed structures, a standard testing framework, deferred function calls, and so on. You can also directly include c headers directly in zig code, so this gives you a pathway to modernizing C Code incrementally.

cercatrova 4y ago
But the problems still remain? The borrow checker is an automated way of what one would normally check by hand, or in their mind. Removing it means that, just as one does in C, one must still check for memory errors and will more likely miss such errors more than the borrow checker does.
- ok123456 4y ago
  They have a build in arena allocator. That would cover a lot of manual frees. Also they have the defer syntax to defer your call to free. The borrow checker doesn't stop most memory errors, just the easy ones at the cost of making it painful to write basic data structures. There are many memory related CVE on common rust libraries.
  - davidatbu 4y ago
    "The borrow checker stops only easy memory errors" is not the impression I have of Rust, and I would love to learn more about this claim. For example, I'd love to see examples of CVEs on common rust libraries that you mention, if they are caused by safe code (ie, not using `unsafe`, which means the borrow checker is in effect).
    - ok123456 4y ago
      https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RUST+Memory https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RUST+Memory
      - pcwalton 4y ago
        You realize that these are notable because they're so rare, right? The vast majority of these would never even be filed as CVEs in C++. Like, consider https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45695 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4569...: "An issue was discovered in the mopa crate through 2021-06-01 for Rust. It incorrectly relies on Trait memory layout, possibly leading to future occurrences of arbitrary code execution or ASLR bypass." In C++ this would never have been filed, because it didn't actually cause any problems. It was only filed for Rust because Rust has much higher standards around even the possibility of potential memory safety problems than C++ does.
        davidatbu 4y ago
        To add to that, I think the vulnerability is actually caused by unsafe code too: https://github.com/chris-morgan/mopa/issues/13 https://github.com/chris-morgan/mopa/issues/13
      - davidatbu 4y ago
        Out of the 10 top ones in that list about Rust (there's one about C code in GCC), 1. 6 are because of unsafe code. 2. 3 are because of ouf-of-memory (OOM) errors. 3. 1 is due to unsafe code in `tokio`, but I think it's fair to consider unsoundness in tokio's safe abstractions (over unsafe code) as unsoundness in "safe Rust" because the crate is so foundational, even if its third party. Regardless, I don't think any of the above support your claim that "the borrow checker only prevents the easiest memory errors". I imagine one could argue that OOM vulnerabilities are less likely to happen in Zig because of its emphasis on fallible and explicit allocation, but that's still not an argument for the borrow checker only preventing the easiest memory errors I think.
        dundarious 4y ago
  - pcwalton 4y ago
    > The borrow checker doesn't stop most memory errors, just the easy ones at the cost of making it painful to write basic data structures. This is completely untrue. Anyone who has maintained a large Rust project and a large C++ project knows that, empirically, Rust projects have far fewer memory safety problems than C++ projects do.
- olodus 4y ago
  Yes THAT problem still exists. Zig does not try to solve that problem (currently). It tries to solve a lot of other problems with C. Using the ownership model is one way of solving memory problems. There are others. I've seen discussions that zig could have an ownership model at some point, or maybe it will have something other. To lock in on that the ownership model is the be-all-end-all of memory problem solutions is a bit much I would say. Don't get me wrong, the ownership model is a good one and I like that Rust is pushing the frontier in that area, but there is room for other system languages that take other approaches to its design and tries to solve other problems first.
- flohofwoe 4y ago
  Zig isn't "watertight" like Rust, but the memory safety is still much closer to Rust than to C or C++, just because Zig enforces a lot more correctness in the language, and because of runtime checks. And a lot of memory corruption issues in C and C++ are actually side effects of C's and C++'s fairly relaxed approach to things like integer conversions, over/underflow, range checking etc... these are all points that Zig covers (for some of those things even when compiling C/C++ code because of the much stricter default compile options than regular C/C++ compilers). (disclaimer: Zig has or had some pretty big holes around escape-checking function return values - that's something that even C compiler are warning about these days, at least for simple cases - but apparently improving this aspect is on the todo list).
littlestymaar 4y ago
> Not fighting the borrow checker This isn't going to be appealing to Rust current users though, because “fighting the borrow checker” is a learning curve issue, you don't fight the borrow checker anymore once you've internalized its rules. > or making gratuitous copies of data to satisfy the borrow checker. You get it backward. In Rust there's less gratuitous copies, not more, because the ownership rules and the borrow checker gives you compile-time guarantees, while “defensive copies” are common in C++ for instance, “to be safe”.
- ptato 4y ago
  That was not my experience. I still fought the borrow checker after a year of using Rust. And I found many situations while using Rust where I either needed to clone, or use unsafe where it's easier to make a mistake than in other languages because the syntax is extremely unergonomic and the memory semantics are much less clear.
  - kitkat_new 4y ago
    can you give examples please?
    - ptato 4y ago
      It's been ~a year. I can't remember. It usually had to do with the dreaded self referential structures, or interfacing with c libs.
      - littlestymaar 4y ago
        For Self referential struct, the typical answer is twofold: - try to design your code not to need them. - if you really need one, you can either use smart pointers (Rc & RefCell) or use unsafe and use the Pin API to be sure that you won't accidentally move your struct. That being said, it's not easier in C (or at least, it's easier to write, but also very easy to misuse), since a memcopy will silently break your self-referential struct. Do Zig has “Copy constructors” like C++ to avoid this issue?
Tozen 4y ago
> Zig's scope is just to be a better C that's free to add modern features... The thing about that though, is there are a number of better C languages (both old and new) that have various levels of C interop. Languages like: D, Odin, Nim, Vlang, etc...
- ok123456 4y ago
  Eventually someone will make one that's ergonomic enough, provides enough features and can used to gradually refactor existing C with minimal changes code bases that it becomes a commercially viable alternative to just continuing to do maintenance programming on the C code.

cercatrova 4y ago

But the problems still remain? The borrow checker is an automated way of what one would normally check by hand, or in their mind. Removing it means that, just as one does in C, one must still check for memory errors and will more likely miss such errors more than the borrow checker does.

ok123456 4y ago
They have a build in arena allocator. That would cover a lot of manual frees. Also they have the defer syntax to defer your call to free. The borrow checker doesn't stop most memory errors, just the easy ones at the cost of making it painful to write basic data structures. There are many memory related CVE on common rust libraries.
- davidatbu 4y ago
  "The borrow checker stops only easy memory errors" is not the impression I have of Rust, and I would love to learn more about this claim. For example, I'd love to see examples of CVEs on common rust libraries that you mention, if they are caused by safe code (ie, not using `unsafe`, which means the borrow checker is in effect).
  - ok123456 4y ago
    https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RUST+Memory https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RUST+Memory
    - pcwalton 4y ago
      You realize that these are notable because they're so rare, right? The vast majority of these would never even be filed as CVEs in C++. Like, consider https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45695 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4569...: "An issue was discovered in the mopa crate through 2021-06-01 for Rust. It incorrectly relies on Trait memory layout, possibly leading to future occurrences of arbitrary code execution or ASLR bypass." In C++ this would never have been filed, because it didn't actually cause any problems. It was only filed for Rust because Rust has much higher standards around even the possibility of potential memory safety problems than C++ does.
      - davidatbu 4y ago
        To add to that, I think the vulnerability is actually caused by unsafe code too: https://github.com/chris-morgan/mopa/issues/13 https://github.com/chris-morgan/mopa/issues/13
    - davidatbu 4y ago
      Out of the 10 top ones in that list about Rust (there's one about C code in GCC), 1. 6 are because of unsafe code. 2. 3 are because of ouf-of-memory (OOM) errors. 3. 1 is due to unsafe code in `tokio`, but I think it's fair to consider unsoundness in tokio's safe abstractions (over unsafe code) as unsoundness in "safe Rust" because the crate is so foundational, even if its third party. Regardless, I don't think any of the above support your claim that "the borrow checker only prevents the easiest memory errors". I imagine one could argue that OOM vulnerabilities are less likely to happen in Zig because of its emphasis on fallible and explicit allocation, but that's still not an argument for the borrow checker only preventing the easiest memory errors I think.
      - dundarious 4y ago
- pcwalton 4y ago
  > The borrow checker doesn't stop most memory errors, just the easy ones at the cost of making it painful to write basic data structures. This is completely untrue. Anyone who has maintained a large Rust project and a large C++ project knows that, empirically, Rust projects have far fewer memory safety problems than C++ projects do.
olodus 4y ago
Yes THAT problem still exists. Zig does not try to solve that problem (currently). It tries to solve a lot of other problems with C. Using the ownership model is one way of solving memory problems. There are others. I've seen discussions that zig could have an ownership model at some point, or maybe it will have something other. To lock in on that the ownership model is the be-all-end-all of memory problem solutions is a bit much I would say. Don't get me wrong, the ownership model is a good one and I like that Rust is pushing the frontier in that area, but there is room for other system languages that take other approaches to its design and tries to solve other problems first.
flohofwoe 4y ago
Zig isn't "watertight" like Rust, but the memory safety is still much closer to Rust than to C or C++, just because Zig enforces a lot more correctness in the language, and because of runtime checks. And a lot of memory corruption issues in C and C++ are actually side effects of C's and C++'s fairly relaxed approach to things like integer conversions, over/underflow, range checking etc... these are all points that Zig covers (for some of those things even when compiling C/C++ code because of the much stricter default compile options than regular C/C++ compilers). (disclaimer: Zig has or had some pretty big holes around escape-checking function return values - that's something that even C compiler are warning about these days, at least for simple cases - but apparently improving this aspect is on the todo list).

littlestymaar 4y ago

> Not fighting the borrow checker This isn't going to be appealing to Rust current users though, because “fighting the borrow checker” is a learning curve issue, you don't fight the borrow checker anymore once you've internalized its rules. > or making gratuitous copies of data to satisfy the borrow checker. You get it backward. In Rust there's less gratuitous copies, not more, because the ownership rules and the borrow checker gives you compile-time guarantees, while “defensive copies” are common in C++ for instance, “to be safe”.

ptato 4y ago
That was not my experience. I still fought the borrow checker after a year of using Rust. And I found many situations while using Rust where I either needed to clone, or use unsafe where it's easier to make a mistake than in other languages because the syntax is extremely unergonomic and the memory semantics are much less clear.
- kitkat_new 4y ago
  can you give examples please?
  - ptato 4y ago
    It's been ~a year. I can't remember. It usually had to do with the dreaded self referential structures, or interfacing with c libs.
    - littlestymaar 4y ago
      For Self referential struct, the typical answer is twofold: - try to design your code not to need them. - if you really need one, you can either use smart pointers (Rc & RefCell) or use unsafe and use the Pin API to be sure that you won't accidentally move your struct. That being said, it's not easier in C (or at least, it's easier to write, but also very easy to misuse), since a memcopy will silently break your self-referential struct. Do Zig has “Copy constructors” like C++ to avoid this issue?

Tozen 4y ago

> Zig's scope is just to be a better C that's free to add modern features... The thing about that though, is there are a number of better C languages (both old and new) that have various levels of C interop. Languages like: D, Odin, Nim, Vlang, etc...

ok123456 4y ago
Eventually someone will make one that's ergonomic enough, provides enough features and can used to gradually refactor existing C with minimal changes code bases that it becomes a commercially viable alternative to just continuing to do maintenance programming on the C code.