4 ms·

So why would I be interested in Zig rather than Rust, if I'm trying to replace C code with something safer and more modern?

AndyKelley 9y ago
https://github.com/zig-lang/zig/wiki/Why-Zig-When-There-is-Already-CPP%2C-D%2C-and-Rust%3F https://github.com/zig-lang/zig/wiki/Why-Zig-When-There-is-A...
- namelost 9y ago
  Lack of operator overloading limits the audience of a language to non-numerical applications (e.g. no gamedev).
  - AndyKelley 9y ago
    One counter example: https://youtu.be/rX0ItVEVjHc?t=589 https://youtu.be/rX0ItVEVjHc?t=589
    - gravypod 9y ago
      In that video he just said that operator overloading was good for math operations. That's not a counter example.
      - abiox 9y ago
        even for math operations, "we'll let it go" would seem to be a different sentiment than "good". :)
  - lucozade 9y ago
    Limit the audience for end user applications, possibly. If this were generally true then C wouldn't be used in numerical applications which is clearly not the case. I think this is the wrong way to look at it. Where C still has advantages over many languages is where the developer's primary mental model is the machine the program is running on. That's why it's used for device drivers and low level library work. Over the last couple of decades, C has become less and less good at this task as the C model and the machine have steadily diverged. At the same time, it's limitations have been exposed more and more. In my view, Zig is aiming at this space i.e. where the developer is primarily interested in what the machine is doing. What they have done is kept the C model (largely) but mitigated or removed some of the egregious failings of C. Zig may not be unique in doing this but it's definitely quite rare. Rust, Go, Swift et al aren't attempting to do this. This isn't a criticism just a perfectly legitimate difference of priority. As I failed my soothsaying exam, I'm in no position to predict which, if any, will succeed. I hope (without much justification) that having language diversity will encourage natural selection.
ngrilly 9y ago
For example: "The motivation for this design philosophy is to enable users to write any manner of custom allocator strategy they find necessary, instead of forcing them or even encouraging them into a particular strategy that may not suitable for their needs. For example, Rust seems to encourage a single global allocator strategy, which is not suitable for many usecases such as OS development and high-performance game development."
- steveklabnik 9y ago
  NB: that is sorta true right now (as the sentence says, "seems to"), but it's also an area of active work; we don't expect Rust to end up that way. To elaborate a bit: Right now, the standard library relies on an allocator. The language itself does not. If you want to write your own types and back them up by your own allocator, you can 100% do that today. But that doesn't help you with any of the stuff in the stdlib. We have work on: 1. A trait for allocation, so that allocators can have the same APIs. https://github.com/rust-lang/rust/issues/32838 https://github.com/rust-lang/rust/issues/32838 2. Swapping out that allocator entirely, wholesale. Tor and Firefox both want this. https://github.com/rust-lang/rust/issues/27389 https://github.com/rust-lang/rust/issues/27389 3. Allowing you to swap out the allocator of stdlib types on a per-instance basis; this almost had an RFC for the needed machinery, but was postponed. Will probably come up again in the coming year after #1 & #2 get resolved.
  - ngrilly 9y ago
    Duly noted ;-)
iainmerrick 9y ago
Compilation speed maybe? If you see quick compilation as an advantage Go has over Rust, but want Rust’s robust error checking and you don’t like Go’s reliance on garbage collection, Zig might be interesting.
audunw 9y ago
Rust is a pretty complex language. It's more of a C++ replacement. Zig is a C replacement: a dead simple language for low-level development, partly disregarding memory safety (there seems to be some improvements, but only where it doesn't make the language more complex). Could you ever imagine writing something like Tiny C-Compiler for Rust? C is like fancy assembly. Zig seems to fit into that niche quite well, but doing it in a more disciplined and modern way.
- catnaroek 9y ago
  Every non-memory-safe language ought to come with a formal semantics. If the type checker can't semi-decide whether the program has a well-defined meaning, at least you ought to have the tools to do it on your own. (This isn't a Zig-specific complaint. I've made exactly the same remark about unsafe Rust in the past.) I'm afraid that the illusion of simplicity would be lost in the formalization process.

AndyKelley 9y ago

https://github.com/zig-lang/zig/wiki/Why-Zig-When-There-is-Already-CPP%2C-D%2C-and-Rust%3F https://github.com/zig-lang/zig/wiki/Why-Zig-When-There-is-A...

namelost 9y ago
Lack of operator overloading limits the audience of a language to non-numerical applications (e.g. no gamedev).
- AndyKelley 9y ago
  One counter example: https://youtu.be/rX0ItVEVjHc?t=589 https://youtu.be/rX0ItVEVjHc?t=589
  - gravypod 9y ago
    In that video he just said that operator overloading was good for math operations. That's not a counter example.
    - abiox 9y ago
      even for math operations, "we'll let it go" would seem to be a different sentiment than "good". :)
- lucozade 9y ago
  Limit the audience for end user applications, possibly. If this were generally true then C wouldn't be used in numerical applications which is clearly not the case. I think this is the wrong way to look at it. Where C still has advantages over many languages is where the developer's primary mental model is the machine the program is running on. That's why it's used for device drivers and low level library work. Over the last couple of decades, C has become less and less good at this task as the C model and the machine have steadily diverged. At the same time, it's limitations have been exposed more and more. In my view, Zig is aiming at this space i.e. where the developer is primarily interested in what the machine is doing. What they have done is kept the C model (largely) but mitigated or removed some of the egregious failings of C. Zig may not be unique in doing this but it's definitely quite rare. Rust, Go, Swift et al aren't attempting to do this. This isn't a criticism just a perfectly legitimate difference of priority. As I failed my soothsaying exam, I'm in no position to predict which, if any, will succeed. I hope (without much justification) that having language diversity will encourage natural selection.

ngrilly 9y ago

For example: "The motivation for this design philosophy is to enable users to write any manner of custom allocator strategy they find necessary, instead of forcing them or even encouraging them into a particular strategy that may not suitable for their needs. For example, Rust seems to encourage a single global allocator strategy, which is not suitable for many usecases such as OS development and high-performance game development."

steveklabnik 9y ago
NB: that is sorta true right now (as the sentence says, "seems to"), but it's also an area of active work; we don't expect Rust to end up that way. To elaborate a bit: Right now, the standard library relies on an allocator. The language itself does not. If you want to write your own types and back them up by your own allocator, you can 100% do that today. But that doesn't help you with any of the stuff in the stdlib. We have work on: 1. A trait for allocation, so that allocators can have the same APIs. https://github.com/rust-lang/rust/issues/32838 https://github.com/rust-lang/rust/issues/32838 2. Swapping out that allocator entirely, wholesale. Tor and Firefox both want this. https://github.com/rust-lang/rust/issues/27389 https://github.com/rust-lang/rust/issues/27389 3. Allowing you to swap out the allocator of stdlib types on a per-instance basis; this almost had an RFC for the needed machinery, but was postponed. Will probably come up again in the coming year after #1 & #2 get resolved.
- ngrilly 9y ago
  Duly noted ;-)

iainmerrick 9y ago

Compilation speed maybe? If you see quick compilation as an advantage Go has over Rust, but want Rust’s robust error checking and you don’t like Go’s reliance on garbage collection, Zig might be interesting.

audunw 9y ago

Rust is a pretty complex language. It's more of a C++ replacement. Zig is a C replacement: a dead simple language for low-level development, partly disregarding memory safety (there seems to be some improvements, but only where it doesn't make the language more complex). Could you ever imagine writing something like Tiny C-Compiler for Rust? C is like fancy assembly. Zig seems to fit into that niche quite well, but doing it in a more disciplined and modern way.

catnaroek 9y ago
Every non-memory-safe language ought to come with a formal semantics. If the type checker can't semi-decide whether the program has a well-defined meaning, at least you ought to have the tools to do it on your own. (This isn't a Zig-specific complaint. I've made exactly the same remark about unsafe Rust in the past.) I'm afraid that the illusion of simplicity would be lost in the formalization process.