9 ms·

My homepage takes 73ms to rebuild: 17ms to recompile the static site generator, then 56ms to run it. andy@bark ~/d/andrewkelley.me (master)> zig build --wa

My homepage takes 73ms to rebuild: 17ms to recompile the static site generator, then 56ms to run it. andy@bark ~/d/andrewkelley.me (master)> zig build --watch -fincremental Build Summary: 3/3 steps succeeded install success └─ run exe compile success 57ms MaxRSS:3M └─ compile exe compile Debug native success 331ms Build Summary: 3/3 steps succeeded install success └─ run exe compile success 56ms MaxRSS:3M └─ compile exe compile Debug native success 17ms watching 75 directories, 1 processes

echelon 1y ago
Zig is a small and simple language. It doesn't need a complicated compiler. Rust is a large and robust language meant for serious systems programming. The scope of problems Rust addresses is large, and Rust seeks to be deployed to very large scale software problems. These two are not the same and do not merit an apples to apples comparison. edit: I made some changes to my phrasing. I described Zig as a "toy" language, which wasn't the right wording. These languages are at different stages of maturity, have different levels of complexity, and have different customers. They shouldn't be measured against each other so superficially.
- steveklabnik 1y ago
  Come on now. This isn't acceptable behavior. (EDIT: The parent has since edited this comment to contain more than just "zig bad rust good", but I still think the combative-ness and insulting tone at the time I made this comment isn't cool.)
  - echelon 1y ago
    > but I still think the combative-ness and insulting tone at the time I made this comment isn't cool Respectfully, the parent only offers up a Zig compile time metric. That's it. That's the entire comment. This HN post about Rust is now being dominated by a cheap shot Zig one liner humblebrag from the lead author of Zig. I think this thread needs a little more nuance.
    - steveklabnik 1y ago
      FWIW, I think your revised comment is far better, even though I disagree with some of the framing, there's at least some substance there. Being frustrated by perceived bad behavior doesn't mean responding with more bad behavior is a good way to improve the discourse, if that's your goal here.
      - echelon 1y ago
        You're 100% right, Steve. Thank you for your voice of moderation. You've been amazing to this community.
        steveklabnik 1y ago
        It's all good. I'm very guilty of bad behavior myself a lot of the time. It's on all of us to give gentle nudges when we see each other getting out of line. I deserve to be told the same if you see me doing this too!
    - Mawr 1y ago
      > Respectfully, the parent only offers up a Zig compile time metric. That's it. That's the entire comment. That's correct, but slinging cheap shots at each other is not how discussions on this site are supposed to be. > I think this thread needs a little more nuance. Yes, but your comment offers none.
- ummonk 1y ago
  This is an amusing argument to make in favor of Rust, since it's exactly the kind of dismissive statement that Ada proponents make about other languages including Rust.
taylorallred 1y ago
@AndyKelley I'm super curious what you think the main factors are that make languages like Zig super fast at compiling where languages like Rust and Swift are quite slow. What's the key difference?
- AndyKelley 1y ago
  Basically, not depending on LLVM or LLD. The above is only possible because we invested years into making our own x86_64 backend and our own linker. You can see all the people ridiculing this decision 2 years ago https://news.ycombinator.com/item?id=36529456 https://news.ycombinator.com/item?id=36529456
  - unclad5968 1y ago
    LLVM isnt a good scapegoat. A C application equivalent in size to a rust or c++ application will compile an order of magnitude quicker and they all use LLVM. I'm not a compiler expert, but it doesn't seem right to me that the only possible path to quick compilation for Zig was a custom backend.
    - MobiusHorizons 1y ago
      Be that as it may, many C compilers are still an order of magnitude faster than LLVM. Probably the best example is tcc, although it is not the only one. C is a much simpler language than rust, so it is expected that compilation should take less time for C. That doesn’t mean llvm isn’t a significant contributor to compilation speed. I believe cranelift compilation of rust is also much faster than the llvm path
      - unclad5968 1y ago
        > That doesn’t mean llvm isn’t a significant contributor to compilation speed. That's not what I said. I said it's unlikely that fast compilation cannot be achieved while using LLVM which, I would argue, is proven by the existence of a fast compiler that uses LLVM.
    - 1y ago
vlovich123 1y ago
Zig isn’t memory safe though right?
- pixelpoet 1y ago
  It isn't a lot of things, but I would argue that its exceptionally (heh) good exception handling model / philosophy (making it good, required, and performant) is more important than memory safety, especially when a lot of performance-oriented / bit-banging Rust code just gets shoved into Unsafe blocks anyway. Even C/C++ can be made memory safe, cf. https://github.com/pizlonator/llvm-project-deluge https://github.com/pizlonator/llvm-project-deluge What I'm more interested to know is what the runtime performance tradeoff is like now; one really has to assume that it's slower than LLVM-generated code, otherwise that monumental achievement seems to have somehow been eclipsed in very short time, with much shorter compile times to boot.
  - vlovich123 1y ago
    > Even C/C++ can be made memory safe, cf. https://github.com/pizlonator/llvm-project-deluge https://github.com/pizlonator/llvm-project-deluge > Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (each pointer in memory has a corresponding capability, not visible to the C address space) With significant performance and memory overhead. That just isn't the same ballpark that Rust is playing in although hugely important if you want to bring forward performance insensitive C code into a more secure execution environment.
    - mike_hearn 1y ago
      Fil-C has advanced a lot since I last looked at it: > Fil-C is currently 1.5x slower than normal C in good cases, and about 4x slower in the worst cases. with room for optimization still. Compatibility has improved massively too, due to big changes to how it works. The early versions were kind of toys, but if Filip's claims about the current version hold up then this is starting to look like a very useful bit of kit. And he has the kind of background that means we should take this seriously. There's a LOT of use cases for taking stuff written in C and eliminating memory safety issues for only a 50% slowdown.
whoisyc 1y ago
Just like every submission about C/C++ gets a comment about how great Rust is, every submission about Rust gets a comment about how great Zig is. Like a clockwork. Edit: apparently I am replying to the main Zig author? Language evangelism is by far the worst part of Rust and has likely stirred up more anti Rust sentiment than “converting” people to Rust. If you truly care for your language you should use whatever leverage you have to steer your community away from evangelism, not embrace it.
- AlienRobot 1y ago
  If you can't be proud about a programming language you made what is even the point?
- frollogaston 1y ago
  It's unlikely that anyone was going to use Rust anyway but decided not to because they got too annoyed hearing about it.
qualeed 1y ago
Neat, I guess? This comment would be a lot better if it engaged with the posted article, or really had any sort of insight beyond a single compile time metric. What do you want me to take away from your comment? Zig good and Rust bad?
- kristoff_it 1y ago
  I think the most relevant thing is that building a simple website can (and should) take milliseconds, not minutes, and that -- quoting from the post: > A brief note: 50 seconds is fine, actually! 50 seconds should actually not be considered fine.
  - qualeed 1y ago
    As you've just demonstrated, that point can be made without even mentioning Zig, let alone copy/pasting some compile time stuff with no other comment or context. Which is why I thought (well, hoped) there might be something more to it than just a dunk attempt. Now we get all of this off-topic discussion about Zig. Which I guess is good for you Zig folk... But it's pretty off-putting for me. whoisyc's comment is extremely on point. As the VP of community, I would really encourage thinking about what they said.
    - kristoff_it 1y ago
      > As you've just demonstrated, that point can be made without even mentioning Zig, let alone copy/pasting some compile time stuff with no other comment or context. Which is why I thought (well, hoped) there might be something more to it than just a dunk attempt. Having concrete proof that something can be done more efficiently is extremely important and, no, I haven't "demonstrated" anything, since my earlier comment would have had way less substance to it without the previous context. The comment from Andrew is not just random compiler stats, but a datapoint showing a comparable example having dramatically different performance characteristics. You can find in this very HN submission various comments that assume that Rust's compiler performance is impossible to improve because of reasons that actually are mostly (if not entirely) irrelevant. Case in point, see people talking about how Rust compilation must take longer because of the borrow checker (and other safety checks) and Steve pointing out that, no, actually that part of the compilation pipeline is very small. > Now we get all of this off-topic discussion about Zig. So no, I would argue the opposite: this discussion is very much on topic.
ww520 1y ago
Nice. Didn't realize zig build has --watch and -fincremental added. I was mostly using "watchexec -e zig zig build" for recompile on file changes.
- Graziano_M 1y ago
  New to 0.14.0!
nicoburns 1y ago
My non-static Rust website (includes an actual webserver as well as a react-like framework for templating) takes 1.25s to do an incremental recompile with "cargo watch" (which is an external watcher that just kills the process and reruns "cargo run"). And it can be considerably faster if you use something like subsecond[0] (which does incremental linking and hotpatches the running binary). It's not quite as fast as Zig, but it's close. However, if that 331ms build above is a clean (uncached) build then that's a lot faster than a clean build of my website which takes ~12s. [0]: https://news.ycombinator.com/item?id=44369642 https://news.ycombinator.com/item?id=44369642
- AndyKelley 1y ago
  The 331ms time is mostly uncached. In this case the build script was already cached (must be re-done if the build script is edited), and compiler_rt was already cached (must be done exactly once per target; almost never rebuilt).
  - nicoburns 1y ago
    Impressive!
deleted 1y ago
[deleted]

echelon 1y ago

Zig is a small and simple language. It doesn't need a complicated compiler. Rust is a large and robust language meant for serious systems programming. The scope of problems Rust addresses is large, and Rust seeks to be deployed to very large scale software problems. These two are not the same and do not merit an apples to apples comparison. edit: I made some changes to my phrasing. I described Zig as a "toy" language, which wasn't the right wording. These languages are at different stages of maturity, have different levels of complexity, and have different customers. They shouldn't be measured against each other so superficially.

steveklabnik 1y ago
Come on now. This isn't acceptable behavior. (EDIT: The parent has since edited this comment to contain more than just "zig bad rust good", but I still think the combative-ness and insulting tone at the time I made this comment isn't cool.)
- echelon 1y ago
  > but I still think the combative-ness and insulting tone at the time I made this comment isn't cool Respectfully, the parent only offers up a Zig compile time metric. That's it. That's the entire comment. This HN post about Rust is now being dominated by a cheap shot Zig one liner humblebrag from the lead author of Zig. I think this thread needs a little more nuance.
  - steveklabnik 1y ago
    FWIW, I think your revised comment is far better, even though I disagree with some of the framing, there's at least some substance there. Being frustrated by perceived bad behavior doesn't mean responding with more bad behavior is a good way to improve the discourse, if that's your goal here.
    - echelon 1y ago
      You're 100% right, Steve. Thank you for your voice of moderation. You've been amazing to this community.
      - steveklabnik 1y ago
        It's all good. I'm very guilty of bad behavior myself a lot of the time. It's on all of us to give gentle nudges when we see each other getting out of line. I deserve to be told the same if you see me doing this too!
  - Mawr 1y ago
    > Respectfully, the parent only offers up a Zig compile time metric. That's it. That's the entire comment. That's correct, but slinging cheap shots at each other is not how discussions on this site are supposed to be. > I think this thread needs a little more nuance. Yes, but your comment offers none.
ummonk 1y ago
This is an amusing argument to make in favor of Rust, since it's exactly the kind of dismissive statement that Ada proponents make about other languages including Rust.

taylorallred 1y ago

@AndyKelley I'm super curious what you think the main factors are that make languages like Zig super fast at compiling where languages like Rust and Swift are quite slow. What's the key difference?

AndyKelley 1y ago
Basically, not depending on LLVM or LLD. The above is only possible because we invested years into making our own x86_64 backend and our own linker. You can see all the people ridiculing this decision 2 years ago https://news.ycombinator.com/item?id=36529456 https://news.ycombinator.com/item?id=36529456
- unclad5968 1y ago
  LLVM isnt a good scapegoat. A C application equivalent in size to a rust or c++ application will compile an order of magnitude quicker and they all use LLVM. I'm not a compiler expert, but it doesn't seem right to me that the only possible path to quick compilation for Zig was a custom backend.
  - MobiusHorizons 1y ago
    Be that as it may, many C compilers are still an order of magnitude faster than LLVM. Probably the best example is tcc, although it is not the only one. C is a much simpler language than rust, so it is expected that compilation should take less time for C. That doesn’t mean llvm isn’t a significant contributor to compilation speed. I believe cranelift compilation of rust is also much faster than the llvm path
    - unclad5968 1y ago
      > That doesn’t mean llvm isn’t a significant contributor to compilation speed. That's not what I said. I said it's unlikely that fast compilation cannot be achieved while using LLVM which, I would argue, is proven by the existence of a fast compiler that uses LLVM.
  - 1y ago

vlovich123 1y ago

Zig isn’t memory safe though right?

pixelpoet 1y ago
It isn't a lot of things, but I would argue that its exceptionally (heh) good exception handling model / philosophy (making it good, required, and performant) is more important than memory safety, especially when a lot of performance-oriented / bit-banging Rust code just gets shoved into Unsafe blocks anyway. Even C/C++ can be made memory safe, cf. https://github.com/pizlonator/llvm-project-deluge https://github.com/pizlonator/llvm-project-deluge What I'm more interested to know is what the runtime performance tradeoff is like now; one really has to assume that it's slower than LLVM-generated code, otherwise that monumental achievement seems to have somehow been eclipsed in very short time, with much shorter compile times to boot.
- vlovich123 1y ago
  > Even C/C++ can be made memory safe, cf. https://github.com/pizlonator/llvm-project-deluge https://github.com/pizlonator/llvm-project-deluge > Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (each pointer in memory has a corresponding capability, not visible to the C address space) With significant performance and memory overhead. That just isn't the same ballpark that Rust is playing in although hugely important if you want to bring forward performance insensitive C code into a more secure execution environment.
  - mike_hearn 1y ago
    Fil-C has advanced a lot since I last looked at it: > Fil-C is currently 1.5x slower than normal C in good cases, and about 4x slower in the worst cases. with room for optimization still. Compatibility has improved massively too, due to big changes to how it works. The early versions were kind of toys, but if Filip's claims about the current version hold up then this is starting to look like a very useful bit of kit. And he has the kind of background that means we should take this seriously. There's a LOT of use cases for taking stuff written in C and eliminating memory safety issues for only a 50% slowdown.

whoisyc 1y ago

Just like every submission about C/C++ gets a comment about how great Rust is, every submission about Rust gets a comment about how great Zig is. Like a clockwork. Edit: apparently I am replying to the main Zig author? Language evangelism is by far the worst part of Rust and has likely stirred up more anti Rust sentiment than “converting” people to Rust. If you truly care for your language you should use whatever leverage you have to steer your community away from evangelism, not embrace it.

AlienRobot 1y ago
If you can't be proud about a programming language you made what is even the point?
frollogaston 1y ago
It's unlikely that anyone was going to use Rust anyway but decided not to because they got too annoyed hearing about it.

qualeed 1y ago

Neat, I guess? This comment would be a lot better if it engaged with the posted article, or really had any sort of insight beyond a single compile time metric. What do you want me to take away from your comment? Zig good and Rust bad?

kristoff_it 1y ago
I think the most relevant thing is that building a simple website can (and should) take milliseconds, not minutes, and that -- quoting from the post: > A brief note: 50 seconds is fine, actually! 50 seconds should actually not be considered fine.
- qualeed 1y ago
  As you've just demonstrated, that point can be made without even mentioning Zig, let alone copy/pasting some compile time stuff with no other comment or context. Which is why I thought (well, hoped) there might be something more to it than just a dunk attempt. Now we get all of this off-topic discussion about Zig. Which I guess is good for you Zig folk... But it's pretty off-putting for me. whoisyc's comment is extremely on point. As the VP of community, I would really encourage thinking about what they said.
  - kristoff_it 1y ago
    > As you've just demonstrated, that point can be made without even mentioning Zig, let alone copy/pasting some compile time stuff with no other comment or context. Which is why I thought (well, hoped) there might be something more to it than just a dunk attempt. Having concrete proof that something can be done more efficiently is extremely important and, no, I haven't "demonstrated" anything, since my earlier comment would have had way less substance to it without the previous context. The comment from Andrew is not just random compiler stats, but a datapoint showing a comparable example having dramatically different performance characteristics. You can find in this very HN submission various comments that assume that Rust's compiler performance is impossible to improve because of reasons that actually are mostly (if not entirely) irrelevant. Case in point, see people talking about how Rust compilation must take longer because of the borrow checker (and other safety checks) and Steve pointing out that, no, actually that part of the compilation pipeline is very small. > Now we get all of this off-topic discussion about Zig. So no, I would argue the opposite: this discussion is very much on topic.

ww520 1y ago

Nice. Didn't realize zig build has --watch and -fincremental added. I was mostly using "watchexec -e zig zig build" for recompile on file changes.

Graziano_M 1y ago
New to 0.14.0!

nicoburns 1y ago

My non-static Rust website (includes an actual webserver as well as a react-like framework for templating) takes 1.25s to do an incremental recompile with "cargo watch" (which is an external watcher that just kills the process and reruns "cargo run"). And it can be considerably faster if you use something like subsecond[0] (which does incremental linking and hotpatches the running binary). It's not quite as fast as Zig, but it's close. However, if that 331ms build above is a clean (uncached) build then that's a lot faster than a clean build of my website which takes ~12s. [0]: https://news.ycombinator.com/item?id=44369642 https://news.ycombinator.com/item?id=44369642

AndyKelley 1y ago
The 331ms time is mostly uncached. In this case the build script was already cached (must be re-done if the build script is edited), and compiler_rt was already cached (must be done exactly once per target; almost never rebuilt).
- nicoburns 1y ago
  Impressive!

deleted 1y ago

[deleted]