Hacker News

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?

Wow that’s gnarly it’s using dynamic dispatch. I mean I get it, but I thought zig was some sort of performance demon.

The parent seems to be talking about efficient code style, not necessarily performance implementation, as they go on to discuss how it looks.

That is, I think the point was DevX not io performance.

> If so, does that mean that every function in zig is a stackless coroutine?

No and yes.

If you're using Io.Threaded, then the concurrency model is multithreading and calling Future.await will block your thread on a OS futex.

If you're using Io.Evented, then the concurrency model is green threads / fibers and calling Future.await will suspend the current green thread by yielding (swapping CPU state with another fiber).

Zig currently does not support stackless coroutines so today you can't have that, but we used to have them (pre self-hosted compiler), and there's an accepted proposal to bring them back, in which case any function that calls await, or that otherwise has a suspension point, would have to be transformed into a stackless coroutine by the compiler, yes. The plan is for that to happen transparently without requiring an `async` annotation in the function signature, like we already did in the past.

This is an old post of mine that explains how that worked at a high level: https://kristoff.it/blog/zig-colorblind-async-await/

For future reference you can format code on hn with a newline first then indenting each line by 2+ spaces. (Rather than triple tick)

> It doesnt let you have unused variables

Ugh. This is something I hate about Go. I would be happy to have unused variables generate warnings, but as errors, they turn the toolchain into an adversary.

It's common for me to temporarily comment out a variable's use when developing new code, as I experiment with ideas. It's even more common when working in unfamiliar code, such as tracking down a bug or incrementally adding a new feature. It's an important part of my exploration process.

When I hit Compile at that point, I expect the compiler to build the work-in-progress exactly as it is in that moment. Executing the output allows me to spot check the snapshot's behavior against my expectations and mental model. The compile step also assures me that no syntax errors have crept in while I was focused on the logic flow or general shape of the code.

When a compiler refuses to do its job, and instead barfs up spurious errors complaining about unused variables, it brings my workflow to a screeching halt. In order to make progress, I am forced to abruptly leave my current context to visit all the different places where those variables are introduced, edit them, try again, discover that those forced edits have left more variables unused, and repeat the process until the combative compiler shuts up and does what I told it to do in the first place. By the time I'm allowed to return to what I was doing, my train of thought has been derailed, the bits of logic that I had been juggling have fallen to the ground, and my focus destroyed. And then, once I have recovered my original thoughts and seen the output of my snapshot build, I have to go back and revert all those forced edits before I can resume my work.

What an aggravating, disruptive, and completely unnecessary waste of my time and attention.

I hope Andrew has the good sense to let errors of this kind be silenced or demoted to warnings, perhaps with a compiler flag or debug build mode.

The unused variable error drives me insane

If they wanted the release build to be an error I wouldn't care. Having the current solution be "have the editor automatically change code to include or remove the underscore" is so wrong to me. Just invented a problem that needs tooling to modify source code to fix.

I love Zig and I am generally very happy with Andrew's benevolent dictatorship and the benefits of having one single smart tasteful person in charge of decisions, but the unused variable one really hurts. My guess is that he's seen what a mess C code can be with regard to warnings and so is just totally unwilling to compromise by adding the concept of warnings to Zig. But if I had one wish about the language, it would be for a command-line flag to disable unused variable errors. So much effort has been put into making iteration fast (all this build system stuff, the custom backend, incremental compilation) and then there's just this giant blocker preventing fast iteration on the editing side.

I agree - can't create and toggle between rough code sketches of functions in a source file without these features. It's more than annoying.

What do you like to ise those features for?

> It doesnt let you have unused variables

Andrew Kelly on that:

https://www.youtube.com/watch?v=iqddnwKF8HQ&t=2927s

Looks like you might be able to get rid of the error easily with annotations.

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.

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.

You both like different types of tinkering.

Some people put a generator on a tesla cybertruck and call that garage tinkering.

Some people make a go-cart out of a lawnmower and call that garage tinkering.

The first is the "batteries included Python" tinkering, the second is the "low level Zig" tinkering.

took me a minute but once i started tinkering with compiled outputs and not dealing with runtimes and venvs my ability to tinker went super crazy. being able to pass something off to my vps with no dependencies if i was tinkering with something hosted was fantastic, or sharing a sidequest with a coworker that's buttoned up and ready to go with no additional environment setup for them

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.

The only language I've historically been able to claim to know without feeling like I'm straight up lying has been Python, and having got past my first maybe 1000 lines of Zig I can say pretty confidently that whatever magic makes Python feel comfortable to write, Zig has too.

It requires more of you in some ways, notably that you have to understand the basics of memory management and the behaviour of the stack, but so far I've found the affordances that the language provides for handling this stuff feel very intuitive.

The only sharp edges I've felt so far have been the sometimes hard to guess locations of things in the standard library, and the permenant anxiety that arises from knowing I'm going to be a few more versions behind the current release with every month that passes.

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.

I once had to write software that would go through whole bunch of PHP code (more than 5000 files), parse / discover certain patterns and write report with proposed fixes or same but with the fixes applied.

For whatever reasons I had to do it in Python. It was total nightmare to debug as the execution speed in debug mode was insanely slow.

I could've written it in C++ in exactly the same time and not to have any of the performance problems.

Crazy flexing a gateway programming language that everyone and their chachi knows.

This has not been my experience.

Not really

I didn't get the same impression. I'm curious to know what created that feeling for you. Perhaps I'm turning a blind eye to something or other?

roc lang looks very interesting, I see they use a lot of Zig and Rust, very unusual combo I think.

Very cool use of Elixir! I have been considering the Fig Stack (F# + Zig) myself, so I'm excited to see Zig being paired with a Functional Language

Interesting. So here's my pretty hacky take on it.

https://github.com/forrestthewoods/anubis/blob/983d8a1b9ea5e...

It invokes zig on a dummy C or CPP file. Then it scrapes the output looking for specific files.

C: crt1.o, libm.so, libpthread.so, libc.so, libdl.so, librt.so, libld.so, libutil.so, libresolv.so, libc_nonshared.a, libcompiler_rt.a

C++: crt1.o, libc++abi.a, libc++.a, libunwind.a, libm.so, libpthread.so, libc.so, libdl.so, librt.so, libld.so, libutil.so, libresolv.so, libc_nonshared.a, libcompiler_rt.a

Zig is also a god send in that it has all the generated glibc header bullshit for Linux.

I've got a system that is able to cross-compile ffmpeg for Linux from Windows. Which is a shockingly painful and rare capability. Linux userspace design is so so so so so bad. So embarrassingly bad.

Andrew Kelley is a damn saint for the mountains he moved for Zig. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

Now I just wish some of this capability was exposed in a slightly more formal capacity so that it could be leveraged by the broader community :)

>(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.

Compared to Rust or C++?

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

> Just creating a file with dummy test like

> if (2 * 2 != 5) { @panic("fail"); }

> And running `zig test file.zig -OReleaseSafe` takes a couple seconds on my computer.

What kind of computer are you on? I just ran that test (latest master build, first run):

   ~ % time zig test file.zig -OReleaseSafe
   file.zig:1:17: error: expected type expression, found '{'
   if (2 * 2 != 5) { @panic("fail"); }
                ^
   zig test file.zig -OReleaseSafe  0.03s user 0.44s system 505% cpu 0.094 total

Also another point. I have some zig projects from couple of months back and they all have build.zig/build.zig.zon. I tried to copy that to the new dummy project I did and of course the API changed and that is broken now (just 15 lines of build.zig code).

This kind of thing just feels unacceptable considering I don't really see ANY improvement on the issues I had from back then.

Also had a similar baffling experience when I last tried to come back to writing Zig. The std.time.Instant or similar API that also exists in rust and most other languages was move to the new Io interface and they also completely removed that std.time.Instant code.

Overall it feels like people developing the tool don't respect the people using the tool. C++ or even Rust are much less enjoyable languages to write compared to Zig so it is really sad that it is not possible to actually use Zig for me.

I thank Go for this. Go's compilation times seemed to inspire other language devs

.....Did you just complain about Rust's "lower adoption" compared to C++, immediately following it by "Zig, on the other hand :eyes_emoji:"

I completely agree. Zig has a nicer DX no doubt - no fighting the borrow checker etc. But if you are are writing software for other people they don't care about how nice your developer experience is, they only want the software to work correctly - and how can you guarantee that the software you wrote does what you expect it to do if it's not memory safe?

writergate was not smooth, a lot of things that moved over to writer (Writer.Allocating for instance) had no documentation and I had to go read the zig source code to figure it out. the docs were just "instead of That use This"

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.

It is. I definitely agree that strings in Zig can be tedious, but the upside is that if you need it, you can build a string library that does everything you want it to do, in the way you want.

For comparison, while Rust offers a very rich string library, it's also very strict about what you can/cannot do with strings, so if your use case falls outside of that you're out of luck. With Zig, you can pretty easily roll your own and make it do what you want. (and when Zig is post 1.0, I imagine there will be some very nice pre-made string libraries by the community etc.)

Tbh I don't know enough Zig to answer that. Can you give an example? E.g. some non-performance-sensitive function that returns a string? In Rust and C++ you can treat the string exactly the same as you would an integer and it's super easy.

In C you have pain. Does the caller allocate a buffer? How does it know how big to make it? Do you have to have separate calls to calculate the required length? Etc. Can Zig work like Rust/C++ and not like C? My impression is that it can't.

Just plain incorrect.. please stop spouting this nonsense, this is not the reason whatsoever.

I bet they'll ultimately reverse course on this, or the there will be a bun / zig fork becomes the de facto bun. Despite what the influencers say, I'm convinced you cannot vibe code a conversion this big. It will need a ton of human intervention. And for brand narrative reasons, Anthropic won't commit to such a path.

> 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.