6 ms·

To each his own, but while I can certainly understand the hesitancy of an architect to pick Zig for a project that is projected to hit 100k+ lines of code, I re

by solatic 8mo ago

To each his own, but while I can certainly understand the hesitancy of an architect to pick Zig for a project that is projected to hit 100k+ lines of code, I really think you're missing out. There is a business case to using Zig today. True in general but in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency. When the system is written in an inefficient language like Python or Node, fundamentally, you have no choice but to start to move the hotpath behind FFI and drop down to a systems language. At that point your choices are basically C, C++, Rust, or Zig. Of the four choices, Zig today is already simplest to learn, with fewer footguns, easier to work with, easier to read and write, and easier to test. And you're not going to write 100k LOC of optimized hotpath code. And when you understand the cost savings involved in reducing your compute needs by sometimes more than 90% by getting the hotpath optimized, you understand that there is very much indeed a business case to learning Zig today.

zozbot234 8mo ago
> ...in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency. That's a very good point, actually. However... > with fewer footguns ..the Crab People[0] would definitely quibble with that particular claim of yours. [0] https://en.wikipedia.org/wiki/Crab_People https://en.wikipedia.org/wiki/Crab_People of course.
- Tuna-Fish 8mo ago
  I would quibble with all of the claims, other than easier to learn. I really see no advantage for Zig over Rust after you get past that 2 first two weeks.
  - bbkane 8mo ago
    Coming from Go, I'm really disappointed in Rust compiler times. I realize they're comparable to C++, and you can structure your crates to minimize compile times, but I don't care. I want instant compilation. Zig is trying to get me instant compilation and I see that as a huge advantage for Zig (even past the first 2 weeks). I'll probably stick with Rust as my "low level language" due to its safety, type system, maturity, library ecosystem, and career opportunities. But I remain jealous of Zig's willingness to do extreme things to make compilation faster.
    - bombela 8mo ago
      On any Go production projects I worked on or near, the incremental compile time was slower than C++ and Rust. A full build was definitely much faster, but not as useful. Especially when using a build system with shared networked caching (Bazel for example). Yes those projects were a bloated mess, as it always seems to be.
      - bbkane 8mo ago
        Re: slower incremental compile times - not my experience, but interesting data point. I'll keep a look out for this.
    - samiv 8mo ago
      The key with c++ is to keep coding while compiling. Otherwise..yeah you're blocked.
      - pjmlp 8mo ago
        The key with C++ is to learn how to use the build system, make use of binary libraries, and if one can afford to use the very latest compiler versions, modules. And avoid header libraries, C++ isn't a scripting language.
- solatic 8mo ago
  Eh, I'd say that Rust has a different set of footguns. You're correct that you won't run into use-after-free footguns, but Rust doesn't protect you from memory leaks, unsafe code is still unsafe, and the borrow checker and Rust's language complexity are their own kind of footguns. But I digress. I was thinking of Zig in comparison to C when I wrote that. I don't have a problem conceding that point, but I still believe the overall argument is correct to point to Zig specifically in the case of writing code to optimize a hotpath behind FFI; it is much easier to get to more optimal code and cross-compilation is easier to boot (i.e. to support Darwin/AppleSilicon for dev laptops, and both Linux/x64 and Linux/arm64 for cloud servers).
  - vlovich123 8mo ago
    > but Rust doesn't protect you from memory leaks In theory no. In practice it really does. > unsafe code is still unsafe Ok, but most rust code is not unsafe while all zig code is unsafe. > and the borrow checker and Rust's language complexity are their own kind of footguns Please elaborate. They are something to learn but I don’t see the footgun. A footgun is a surprisingly defect that’s pointed at your foot and easy to trigger (ie doing something wrong and your foot blows off). I can’t think how the borrow checker causes that when it’s the exact opposite - you can’t ever create a footgun without doing unsafe because it won’t even compile. > but I still believe the overall argument is correct to point to Zig specifically in the case of writing code to optimize a hotpath behind FFI; it is much easier to get to more optimal code and cross-compilation is easier to boot (i.e. to support Darwin/AppleSilicon for dev laptops, and both Linux/x64 and Linux/arm64 for cloud servers). I agree cross compilation with zig is significantly easier but Rust isn’t that hard, especially with the cross-rs crate making it significantly simpler. Performance, Rust is going to be better - zig makes you choose between safety and performance and even in unsafe mode there’s various things that cause better codegen. For example zig follows the C path of manual noalias annotations which has been proven to be non scalable and difficult to make operational. Rust does this for all variables automatically because it’s not allowed in the language.
    - program_whiz 8mo ago
      Not the GP, but I've noticed that because if you don't anticipate how you might need to mutate or share state in the future, you can have a "footgun" that forces large-scale code changes for relatively small "feature-level" changes, because of the rust strictness. Its not a footgun in the sense that your code does what you don't expect, its a footgun in that your maintenance and ability to change code is not what you expect (and its easy to do). I'm sure if you are really expert with rust, you see it coming and don't use patterns that will cause waves of changes (but if you're expert at any language you avoid the footguns).
ozgrakkurt 8mo ago
As a counter argument to this. I was able to replicate the subset of zig that I wanted, using c23. And in the end I have absolute stability unless I break things to “improve”. Personally, it is a huge pain to rewrite things and update dependencies because the code I am depending on is moving out from under me. I also found this to be a big problem in Rust. And another huge upside is you have access to best of everything. As an example, I am heavily using fuzz testing and I can very easily use honggfuzz which is the best fuzzer according to all research I could find, and also according to my experience so far. From this perspective, it doesn’t make sense to use zig over c for professional work. If I am writing a lot of code then I don’t want to rewrite it. If am writing a very small amount of code with no dependencies, then it doesn’t matter what I use and this is the only case where I think zig might make sense.
- ozgrakkurt 8mo ago
  Also I was also thinking that breaking doesn’t matter that much, but my opinion changed around 10k lines of code very quickly. At some point I really stopped caring about every piece and wanted to forget about it and move on really
- ozgrakkurt 8mo ago
  To add another point to this. W/e people write online isn’t correct all the time. I was thinking zig compiles super fast but found that c with a good build system and well split header/implementation files is basically instant to compile. You can use thin-lto with cache to have instant recompilation for release builds. Real example: I had to wait some seconds to compile and run benchmarks for a library and it re-compiles instantly (<100ms) with c. Zig does have a single compilation unit and that might have some advantages but in practice it is a hard disadvantage. And I didn’t ever see someone pointing this out online. I would really recommend trying to learn c with modernC book and try to do it with c for people like me building something from scratch
wolvesechoes 8mo ago
> Of the four choices, Zig today is already simplest to learn, Yes, with almost complete lack of documentation and learning materials it is definitely the easiest language to learn.
- LexiMax 8mo ago
  For reference, here's where Zig's documentation lives: https://ziglang.org/learn/ https://ziglang.org/learn/ I remember when learning Zig, the documentation for the language itself was extensive, complete, and easily greppable due to being all on one page. The standard library was a lot less intuitive, but I suspect that has more to do with the amount of churn it's still going through. The build system also needs more extensive documentation in the same way that the stdlib does, but it has a guide that got me reasonably far with what came out of the box.
  - dragonelite 8mo ago
    People do under estimate how nice it is that the language ref or framework/tool documentation is all on one web page i can easily pdf print it and push it to my ipad for reading.
DetroitThrow 8mo ago
>with fewer footguns, easier to work with, easier to read and write, and easier to test. With the exception of fewer foot guns, which Rust definitely takes the cake and Zig is up in second, I'd say Zig is in last place in all of these. This really screams that you aren't aware of C/C++ testing/tooling ecosystem. I say this as a fan of Zig, by the way.

by solatic 8mo ago

zozbot234 8mo ago

> ...in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency. That's a very good point, actually. However... > with fewer footguns ..the Crab People[0] would definitely quibble with that particular claim of yours. [0] https://en.wikipedia.org/wiki/Crab_People https://en.wikipedia.org/wiki/Crab_People of course.

Tuna-Fish 8mo ago
I would quibble with all of the claims, other than easier to learn. I really see no advantage for Zig over Rust after you get past that 2 first two weeks.
- bbkane 8mo ago
  Coming from Go, I'm really disappointed in Rust compiler times. I realize they're comparable to C++, and you can structure your crates to minimize compile times, but I don't care. I want instant compilation. Zig is trying to get me instant compilation and I see that as a huge advantage for Zig (even past the first 2 weeks). I'll probably stick with Rust as my "low level language" due to its safety, type system, maturity, library ecosystem, and career opportunities. But I remain jealous of Zig's willingness to do extreme things to make compilation faster.
  - bombela 8mo ago
    On any Go production projects I worked on or near, the incremental compile time was slower than C++ and Rust. A full build was definitely much faster, but not as useful. Especially when using a build system with shared networked caching (Bazel for example). Yes those projects were a bloated mess, as it always seems to be.
    - bbkane 8mo ago
      Re: slower incremental compile times - not my experience, but interesting data point. I'll keep a look out for this.
  - samiv 8mo ago
    The key with c++ is to keep coding while compiling. Otherwise..yeah you're blocked.
    - pjmlp 8mo ago
      The key with C++ is to learn how to use the build system, make use of binary libraries, and if one can afford to use the very latest compiler versions, modules. And avoid header libraries, C++ isn't a scripting language.
solatic 8mo ago
Eh, I'd say that Rust has a different set of footguns. You're correct that you won't run into use-after-free footguns, but Rust doesn't protect you from memory leaks, unsafe code is still unsafe, and the borrow checker and Rust's language complexity are their own kind of footguns. But I digress. I was thinking of Zig in comparison to C when I wrote that. I don't have a problem conceding that point, but I still believe the overall argument is correct to point to Zig specifically in the case of writing code to optimize a hotpath behind FFI; it is much easier to get to more optimal code and cross-compilation is easier to boot (i.e. to support Darwin/AppleSilicon for dev laptops, and both Linux/x64 and Linux/arm64 for cloud servers).
- vlovich123 8mo ago
  > but Rust doesn't protect you from memory leaks In theory no. In practice it really does. > unsafe code is still unsafe Ok, but most rust code is not unsafe while all zig code is unsafe. > and the borrow checker and Rust's language complexity are their own kind of footguns Please elaborate. They are something to learn but I don’t see the footgun. A footgun is a surprisingly defect that’s pointed at your foot and easy to trigger (ie doing something wrong and your foot blows off). I can’t think how the borrow checker causes that when it’s the exact opposite - you can’t ever create a footgun without doing unsafe because it won’t even compile. > but I still believe the overall argument is correct to point to Zig specifically in the case of writing code to optimize a hotpath behind FFI; it is much easier to get to more optimal code and cross-compilation is easier to boot (i.e. to support Darwin/AppleSilicon for dev laptops, and both Linux/x64 and Linux/arm64 for cloud servers). I agree cross compilation with zig is significantly easier but Rust isn’t that hard, especially with the cross-rs crate making it significantly simpler. Performance, Rust is going to be better - zig makes you choose between safety and performance and even in unsafe mode there’s various things that cause better codegen. For example zig follows the C path of manual noalias annotations which has been proven to be non scalable and difficult to make operational. Rust does this for all variables automatically because it’s not allowed in the language.
  - program_whiz 8mo ago
    Not the GP, but I've noticed that because if you don't anticipate how you might need to mutate or share state in the future, you can have a "footgun" that forces large-scale code changes for relatively small "feature-level" changes, because of the rust strictness. Its not a footgun in the sense that your code does what you don't expect, its a footgun in that your maintenance and ability to change code is not what you expect (and its easy to do). I'm sure if you are really expert with rust, you see it coming and don't use patterns that will cause waves of changes (but if you're expert at any language you avoid the footguns).

ozgrakkurt 8mo ago

As a counter argument to this. I was able to replicate the subset of zig that I wanted, using c23. And in the end I have absolute stability unless I break things to “improve”. Personally, it is a huge pain to rewrite things and update dependencies because the code I am depending on is moving out from under me. I also found this to be a big problem in Rust. And another huge upside is you have access to best of everything. As an example, I am heavily using fuzz testing and I can very easily use honggfuzz which is the best fuzzer according to all research I could find, and also according to my experience so far. From this perspective, it doesn’t make sense to use zig over c for professional work. If I am writing a lot of code then I don’t want to rewrite it. If am writing a very small amount of code with no dependencies, then it doesn’t matter what I use and this is the only case where I think zig might make sense.

ozgrakkurt 8mo ago
Also I was also thinking that breaking doesn’t matter that much, but my opinion changed around 10k lines of code very quickly. At some point I really stopped caring about every piece and wanted to forget about it and move on really
ozgrakkurt 8mo ago
To add another point to this. W/e people write online isn’t correct all the time. I was thinking zig compiles super fast but found that c with a good build system and well split header/implementation files is basically instant to compile. You can use thin-lto with cache to have instant recompilation for release builds. Real example: I had to wait some seconds to compile and run benchmarks for a library and it re-compiles instantly (<100ms) with c. Zig does have a single compilation unit and that might have some advantages but in practice it is a hard disadvantage. And I didn’t ever see someone pointing this out online. I would really recommend trying to learn c with modernC book and try to do it with c for people like me building something from scratch

wolvesechoes 8mo ago

> Of the four choices, Zig today is already simplest to learn, Yes, with almost complete lack of documentation and learning materials it is definitely the easiest language to learn.

LexiMax 8mo ago
For reference, here's where Zig's documentation lives: https://ziglang.org/learn/ https://ziglang.org/learn/ I remember when learning Zig, the documentation for the language itself was extensive, complete, and easily greppable due to being all on one page. The standard library was a lot less intuitive, but I suspect that has more to do with the amount of churn it's still going through. The build system also needs more extensive documentation in the same way that the stdlib does, but it has a guide that got me reasonably far with what came out of the box.
- dragonelite 8mo ago
  People do under estimate how nice it is that the language ref or framework/tool documentation is all on one web page i can easily pdf print it and push it to my ipad for reading.

DetroitThrow 8mo ago

>with fewer footguns, easier to work with, easier to read and write, and easier to test. With the exception of fewer foot guns, which Rust definitely takes the cake and Zig is up in second, I'd say Zig is in last place in all of these. This really screams that you aren't aware of C/C++ testing/tooling ecosystem. I say this as a fan of Zig, by the way.