Zig: Build System Reworked

128 points by tosh 3 hours ago | 31 comments

brabel 36 minutes ago |

I just upgraded some code to Zig 0.16.0 and I am actually really happy with the results. It impacted A LOT of things, but the changes were actually very good and seems to have set the language for a bright future, especially with the new IO mechanism which allows supper efficient code that looks good whether it's implemented single-threaded, multi-threaded or just via an event loop!

If you haven't tried Zig since 0.16.0 was released, I highly recommend having a look. The release notes for this release were huge!!

https://ziglang.org/download/0.16.0/release-notes.html

portly 1 hour ago |

After having used Zig for a couple of months now I am convinced it is a fantastic tool language. You just pick it up to hack some idea together freely. Every time I hit a wall, I find the creators have thought of it already and offers comfort. But nothing gets in your face how to use the programming language "correctly".

For me it is now the go-to "tinker in my garage" language.

ACCount37 1 hour ago | |

Is it really that good?

My go-to "tinker in my garage" language is Python - lightweight syntax that stays out of your face, batteries included, packages for everything that's not included. What's Zig's edge?

miki123211 39 seconds ago | | |

And not only that, if you're doing something in Python, somebody has done it before. Maybe not this exact thing, but something close enough to it. LLMs know it, Stackoverflow knows it, whatever esoteric protocol or file format you're trying to interact with, somebody wrote a library for it in the Python 2 days and has ironed out all the bugs since.

There's no other language quite like Python in this regard. Typescript is a close second, but the lack of metaprogramming facilities, no access to the type annotations at runtime, and the lack of operator overloading make some things needlessly complicated and uglier than they have any right to be.

dmit 49 minutes ago | | |

Have you ever thought "Ugh, this bit of Python code is running much slower than I expected on my computer. Wonder if anyone has written a native library for this"? That's probably the closest use case for someone who matches your description -- a language that is much more ergonomic, much more 'modern' feeling (in all the good ways), while still extremely compatible with C.

As for the language itself, it's going to be more verbose than your Python code. Cons: you'll have to spell out a lot of things that you thought were obvious assumptions. Pros: you will be able to look at a page of code and know with a great degree of certainty that there are no hidden gotchas. No monkey patching, no __init__. Basically, it just does what it says on the tin.

And finally, about the std lib and batteries: there's HTTP(S), compression algorithms, hash algorithms, RNG, I/O, the basic data structures you'd expect, JSON. Third-party libraries, if you choose not to vendor, are handled by including the repository url in a file (also automated by a CLI command), and then adding it to the build script (not automated). The `zig` command handles fetching and ensuring sanity, but otherwise assume a bit of elbow grease will need to be involved.

norman784 1 hour ago | | |

Zig is low level, so it will certainly not replace your python usage, it is more like a modern C than anything else. There’s a video of a recent interview with Andrew Kelley, if you want to watch it to understand better what Zig is for, it’s on Jetbrains YouTube channel.

portly 41 minutes ago | | |

I like that you have more freedom. You can play around with some idea but once you want to do something "serious" you can break into it directly. I start simple but sometimes blip into some performance obsession and I find Zig allows that.

asibahi 57 minutes ago | |

It’s definitely a great tinkering language but .. eh .. the Zig team and community are extremely opinionated about how to use the language correctly.

0x696C6961 12 minutes ago | | |

This has not been my experience.

mcdonje 26 minutes ago | | |

Not really

xtreak29 9 minutes ago |

Bun is moving towards rust but does this also help bun's compilation times?

https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

epolanski 1 hour ago |

This sounds like great news, Zig's compilation times are already terrific and this is going to only make them better.

pjmlp 17 minutes ago | |

Yes, compilation speeds of the 90's are slowly making a return, thankfully.

dmit 1 hour ago | |

> Zig's compilation times are already terrific

In my experience, this (for now) is mostly aspirational. It's obviously a major goal, and there are clear milestones outlined on how to achieve it, but in practice the initial compile of an empty project or the excruciating pause when you `direnv allow` and ZLS needs to be (re)built are not what I'd describe as "terrific".

schaefer 1 hour ago | | |

>(re)built are not what I'd describe as "terrific".

It sounds like you are a strong candidate to try out the new improvements mentioned in this devlog and see what benefits you can get for yourself.

epolanski 1 hour ago | | |

Maybe you're right, but how many other system programming languages toolchains give you sub 50ms recompilations across millions of LoC?

steveharing1 40 minutes ago |

So i checked the license of this project, can anyone pls clarify what is (Expat) after MIT License

papercrane 12 minutes ago | |

There are a number of licenses that are named MIT that are all similar, but not identical.

The "Expat" here is the MIT license variant. It is referring to the Expat XML parsing library that first used this license.

Usually when projects these days use an MIT license this is the version they use.

maleldil 8 minutes ago | |

There are different licenses that used to be referred to as "MIT", and explicitly stating "Expat" tells you which one they're referring to (in this case, the "standard" one). This is largely unnecessary, as nearly all mentions of the MIT license refer to this one.