6 ms·

Why should I use Zig coming from Rust? It doesn't seem that Zig actually solves the memory problems that Rust does.

ok123456 4y ago
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.
    - 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.
xmorse 4y ago
Compile time speed (this is gonna come later with a full hosted compiler, without LLVM)
verdagon 4y ago
I think there's three reasons one might use Zig instead of Rust. These are just opinions, and I would love yall's thoughts. First: there's only a certain amount of effort that one is willing to put into accomplishing one's goals, effort that will be spent on learning tools and building a project. It's not unlimited. If I just want to make a game where a character walks around the world, and I only have 20 or so hours of time before the money / motivation / market opportunity runs out, and it takes 300 hours to master Rust, that's a non-starter. If someone has 2000 hours of time available, then it'll be worth it to learn Rust before starting. If someone has even more than that, then it might be even better to use more advanced proof tools to be even safer than Rust, if safety is an absolute priority. Second: Zig offers a lot more freedom than Rust. The borrow checker historically has difficulties with observers, backreferences, dependency references, several forms of RAII, and graphs. If one just wants a struct to contain a pointer, sometimes it's just easier to use Zig than to change one's entire architecture, which takes a lot of time and effort that one might not want to spend. Of course, this isn't a problem if one uses Rc and RefCell more, which brings its own tradeoffs. Third: There are a lot of cases where the cost of memory unsafety just isn't that high, and Zig's mitigations are more than sufficient. For example, if I'm making a non-safety-critical app or webassembly program that's sandboxed on the client's machine and only talks to its own trusted server, that's more than enough security for a lot of use cases. In these cases, a couple memory safety bugs are just like any other bug, and it's not worth it to spend the time reducing this release's bugs from 23 to 21. This is how it was on Google Earth; the vast majority of our bugs were logic bugs, not memory unsafety (and this was C++). Coming from Rust, the first point likely doesn't apply to you as much. The second and third points might apply, depending on the situation. I think Rust's tradeoffs are stellar for cases like medical devices or HFT where the cost of memory safety and higher latency is much higher than your average webserver (where Go might be a better fit) or your average single player game (where memory unsafety bugs are just inconvenient, not critical). If I was to sum it up, I'd say: Rust is pretty close to perfect on paper, when you don't consider the other human factors, such as limited time, training, or that sometimes it isn't worth it to prove memory safety. When you consider these factors, other languages can make more sense.
- pcwalton 4y ago
  > Third: There are a lot of cases where the cost of memory safety just isn't that high, and Zig's mitigations are more than sufficient. But then why not just use a GC'd language? It isn't 1995 anymore; most apps are written in GC'd languages. C++ makes sense when you already have a lot of C++ code, but if you're talking about new code, I don't see a lot of room for a language without memory safety.
ArrayBoundCheck 4y ago
Despite what students who never programmed professionally say, memory isn't a problem to a significant amount of C and C++ developers. I think it's been a year since I last access an invalid pointer and that only happened because I forgot that I am not suppose to add elements to array in a `for (auto var : array)` loop. It use to be a for index loop and it didn't take long to figure out the change broke something
- davidatbu 4y ago
  I'm one of those who "has never programmed [C/C++] professionally". Isn't your statement at odds with assessment from many big tech companies that memory safety is the prevailing reason for CVEs? I'm sure you're not suggesting that the folks who make these assessments are not experienced C/C++ programmers, so I'm curious about your thinking on this.
nyberg 4y ago
That's the wrong question to ask. Don't compare it to rust's memory safety as otherwise you're pretty much answering your own question with "you shouldn't". Think of what zig has to offer instead and try it out to see how it works.

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.
  - 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.

xmorse 4y ago

Compile time speed (this is gonna come later with a full hosted compiler, without LLVM)

verdagon 4y ago

I think there's three reasons one might use Zig instead of Rust. These are just opinions, and I would love yall's thoughts. First: there's only a certain amount of effort that one is willing to put into accomplishing one's goals, effort that will be spent on learning tools and building a project. It's not unlimited. If I just want to make a game where a character walks around the world, and I only have 20 or so hours of time before the money / motivation / market opportunity runs out, and it takes 300 hours to master Rust, that's a non-starter. If someone has 2000 hours of time available, then it'll be worth it to learn Rust before starting. If someone has even more than that, then it might be even better to use more advanced proof tools to be even safer than Rust, if safety is an absolute priority. Second: Zig offers a lot more freedom than Rust. The borrow checker historically has difficulties with observers, backreferences, dependency references, several forms of RAII, and graphs. If one just wants a struct to contain a pointer, sometimes it's just easier to use Zig than to change one's entire architecture, which takes a lot of time and effort that one might not want to spend. Of course, this isn't a problem if one uses Rc and RefCell more, which brings its own tradeoffs. Third: There are a lot of cases where the cost of memory unsafety just isn't that high, and Zig's mitigations are more than sufficient. For example, if I'm making a non-safety-critical app or webassembly program that's sandboxed on the client's machine and only talks to its own trusted server, that's more than enough security for a lot of use cases. In these cases, a couple memory safety bugs are just like any other bug, and it's not worth it to spend the time reducing this release's bugs from 23 to 21. This is how it was on Google Earth; the vast majority of our bugs were logic bugs, not memory unsafety (and this was C++). Coming from Rust, the first point likely doesn't apply to you as much. The second and third points might apply, depending on the situation. I think Rust's tradeoffs are stellar for cases like medical devices or HFT where the cost of memory safety and higher latency is much higher than your average webserver (where Go might be a better fit) or your average single player game (where memory unsafety bugs are just inconvenient, not critical). If I was to sum it up, I'd say: Rust is pretty close to perfect on paper, when you don't consider the other human factors, such as limited time, training, or that sometimes it isn't worth it to prove memory safety. When you consider these factors, other languages can make more sense.

pcwalton 4y ago
> Third: There are a lot of cases where the cost of memory safety just isn't that high, and Zig's mitigations are more than sufficient. But then why not just use a GC'd language? It isn't 1995 anymore; most apps are written in GC'd languages. C++ makes sense when you already have a lot of C++ code, but if you're talking about new code, I don't see a lot of room for a language without memory safety.

ArrayBoundCheck 4y ago

Despite what students who never programmed professionally say, memory isn't a problem to a significant amount of C and C++ developers. I think it's been a year since I last access an invalid pointer and that only happened because I forgot that I am not suppose to add elements to array in a `for (auto var : array)` loop. It use to be a for index loop and it didn't take long to figure out the change broke something

davidatbu 4y ago
I'm one of those who "has never programmed [C/C++] professionally". Isn't your statement at odds with assessment from many big tech companies that memory safety is the prevailing reason for CVEs? I'm sure you're not suggesting that the folks who make these assessments are not experienced C/C++ programmers, so I'm curious about your thinking on this.

nyberg 4y ago

That's the wrong question to ask. Don't compare it to rust's memory safety as otherwise you're pretty much answering your own question with "you shouldn't". Think of what zig has to offer instead and try it out to see how it works.