Why would I want to use this over, say, Node.js and TypeScript?
Zig: Build System Reworked
81–90 of 263 posts
Re: Zig: Build System Reworked
#82Bun 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...
bun seems to be committed to slop rust already. so, with their ethic, maybe we should just disassociate them from zig and let them go realize their slop dreams? zig is on its way to improving compilation times in its own pace and does so for the benefit of the project and everyone involved, so what is left to care for about bun by anthropic’s past?
> bun seems to be committed to slop rust already. so, with their ethic, maybe we should just disassociate them from zig and let them go realize their slop dreams?
Closing your eyes and pretending a problem does not exist is the a good solution. The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad that they opted to rewrite their entire 1M LOC project into a different language. This is a nightmare scenario for most companies, and will motivate similar sized companies/project to pick another language that will not require this than to risk using Zig. Also, Zig’s flippant attitude about Bun’s request (among other viewpoints) only further adds to why bigger projects would want to stay away from Zig.
Re: Zig: Build System Reworked
#83Earlier quoted context omitted.
Basically what the world has lost by ignoring Modula-2 and Object Pascal, and going down the C path.
The spirit of Pascal lives on in Nim. It's arguably the closest modern language (with a sizeable community) to the Wirthian languages.
I would add that Delphi still follows along, enough for an yearly conference in Germany, and that C# since getting Native AOT and the low level programming improvements, is close enough to Modula-3 design.
There is Swift as well, although quite far from Wirthian compile times.
Re: Zig: Build System Reworked
#84Is there any proposed timeline for a stable release? Big features like the recent async IO shows the language is very unstable right now.
Andrew's take is "it's ready when it's ready but we hope it's good enough before it's fully ready that you want to use it anyway". It's different and I like it. You get one shot at it and may just as well get it right in as many areas as possible.
Yep. He mentioned recently in his JetBrains interview he wants Zig to be a language for the next 50 years. Rushing 1.0 for the sake of signaling to the wider industry today would be actively harmful to that goal.
Re: Zig: Build System Reworked
#85Earlier quoted context omitted.
You have a weirdly restrictive definition of "tinker"
Not really? I've been places, from embedded bare metal to ML AI, and that "embedded bare metal" end is the one place I don't use Python directly in. Embedded bare metal is just ruled by C forever. Bit of a shame, because C is kind of bad at its job, but nothing else has the "compatible with everything" badge of honor. The tooling around embedded devices though? Python.
When I want to tinker it’s usually because I want to make something faster than anyone else has done. Does that help illustrate why some might prefer to tinker in Zig, and why your definition of tinker seems a little narrow?
Re: Zig: Build System Reworked
#86Earlier quoted context omitted.
Rarely. Most tinkering tasks just don't have enough heavy duty computation in them to as much as strain a modern CPU. And most of the rest are covered by packages like numpy or pytorch. For the rare exceptions, I make a C lib and call into it to get my numbers crunched. I get that Zig is a viable replacement for C there. But I don't see it replacing Python.
And if you really need more performance (or, more often, fast startup times), Go gives you 90% of the speed with 30% of the effort. Rust if you really want to squeeze everything that can possibly be squeezed of that CPU.
that’s not what the benchmarks say about Go, and based on multiple reports, Rust does not scale well into large codebases, which eventually become brittle and very difficult to change
Zig is a return to “no magical effects,” except with reasonable safety
Re: Zig: Build System Reworked
#87Earlier quoted context omitted.
Rarely. Most tinkering tasks just don't have enough heavy duty computation in them to as much as strain a modern CPU. And most of the rest are covered by packages like numpy or pytorch. For the rare exceptions, I make a C lib and call into it to get my numbers crunched. I get that Zig is a viable replacement for C there. But I don't see it replacing Python.
Even if you are fine with Python's speed, its memory consumption DOES effect things and can be an extraordinary pain when you need to fit the result of your tinkering in any sort of constrained environment.
By the time I’m memory constrained even on my laptop the processing cost of whatever I’m doing has gone beyond shoving it in the first scripting language I can find. Every device I write code on has at least 16GB RAM - most of them are 64 or 128
Re: Zig: Build System Reworked
#88Earlier quoted context omitted.
This has not been my experience.
https://www.reddit.com/r/Zig/comments/onzsfl/illegal_tabs/
I won't call it "opinionated about how to use the language correctly."
Space is valid and it compile, Tab don't --- that's it.
When one say "opinionated about how to use the language correctly", I would think JavaScript with or without end of statement semicolon and being yell at even when your program works.
Re: Zig: Build System Reworked
#89Why would I want to use this over, say, Node.js and TypeScript?
I suggest you try using Ghostty (written in Zig) for a bit and compare it to another terminal like Hyper (written in JavaScript).
Re: Zig: Build System Reworked
#90Earlier quoted context omitted.
the “(super) efficient” is not there yet. Io is still dynamic dispatch with multiple layers of indirection. afaik it’s slower than before. the upcoming releases are expected to provide a solution to this “dispatch is comptime-known, but still dynamic” problem, and drop the loses in efficiency.
Hmm in the 2025 talk ( https://youtu.be/f30PceqQWko?si=qZESxMaSyt7fYMfz ), Andrew emphasizes that this approach is more efficient than before- even showing compiled assembly iirc. I guess that was a one-off?
My guess is that one of these (Andrew) is measuring syscalls and the other is measuring vtable indirections.