&gt; You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed.I think that&#x27;s a neat idea, but in the reverse: do as much as you can in the lower level language, and only go up to the high level language when the convenience is worth the cost.Roc allows this: every program has a platform written in a low-level language, and then the Roc program uses the API that the platform exposes.<a href="https:&#x2F;&#x2F;www.roc-lang.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.roc-lang.org&#x2F;</a>Then how you want to balance high vs low is of course up to you :^)

The OG of these is probably C and Assembly. C and (Emacs) Lisp is well known. Arguably, it&#x27;s the entire reason we have Python. But if you want to pair Zig against something, I would look at Lua.

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

this was the general motivation for my project zigler:<a href="https:&#x2F;&#x2F;github.com&#x2F;E-xyza&#x2F;zigler" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;E-xyza&#x2F;zigler</a>

There is an idea I&#x27;ve been kicking around for a long time, which I&#x27;ll just call dual programming. The idea is to develop a stack that consists of just two programming languages, 1 higher level language, and one lower level language. You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed. The problem is that unless you already know a low level programming language really well, you&#x27;ll most likely have to re familiarize yourself with the language before doing the low level stuff.This makes Cpp and Rust harder to use then say C, so C becomes the default for me. But C is not without its issues of which we are aware. But Zig feels like it could fill that sweet spot really well, being simple enough that it&#x27;s easier to pick up after a long break, but still coming with a lot of modern tooling that makes programming easier.

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

Hmm in the 2025 talk ( <a href="https:&#x2F;&#x2F;youtu.be&#x2F;f30PceqQWko?si=qZESxMaSyt7fYMfz" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;f30PceqQWko?si=qZESxMaSyt7fYMfz</a> ), Andrew emphasizes that this approach is more efficient than before- even showing compiled assembly iirc. I guess that was a one-off?

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.

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.

Maybe one day it&#x27;d be possible to use these new features, but I find myself using `.use_llvm = true` in my zig builds for stability and lesser tested targets.

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&#x27;s implemented single-threaded, multi-threaded or just via an event loop!If you haven&#x27;t tried Zig since 0.16.0 was released, I highly recommend having a look. The release notes for this release were huge!!<a href="https:&#x2F;&#x2F;ziglang.org&#x2F;download&#x2F;0.16.0&#x2F;release-notes.html" rel="nofollow">https:&#x2F;&#x2F;ziglang.org&#x2F;download&#x2F;0.16.0&#x2F;release-notes.html</a>

The unused variable error drives me insaneIf they wanted the release build to be an error I wouldn&#x27;t care. Having the current solution be &quot;have the editor automatically change code to include or remove the underscore&quot; is so wrong to me. Just invented a problem that needs tooling to modify source code to fix.

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

What do you like to ise those features for?

&gt; But nothing gets in your face how to use the programming language &quot;correctly&quot;.It doesnt let you have unused variables and theres no multiline comment support. These are fairly significant productivity issues for me

Have you ever thought &quot;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&quot;? That&#x27;s probably the closest use case for someone who matches your description -- a language that is much more ergonomic, much more &#x27;modern&#x27; feeling (in all the good ways), while still extremely compatible with C.As for the language itself, it&#x27;s going to be more verbose than your Python code. Cons: you&#x27;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&#x27;s HTTP(S), compression algorithms, hash algorithms, RNG, I&#x2F;O, the basic data structures you&#x27;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 &quot;batteries included Python&quot; tinkering, the second is the &quot;low level Zig&quot; tinkering.

And not only that, if you&#x27;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&#x27;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&#x27;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.

I like that you have more freedom. You can play around with some idea but once you want to do something &quot;serious&quot; 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 &#x2F; 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&#x27;ve written it in C++ in exactly the same time and not to have any of the performance problems.

The only language I&#x27;ve historically been able to claim to know without feeling like I&#x27;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&#x27;ve found the affordances that the language provides for handling this stuff feel very intuitive.The only sharp edges I&#x27;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&#x27;m going to be a few more versions behind the current release with every month that passes.

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

Is it really that good?My go-to &quot;tinker in my garage&quot; language is Python - lightweight syntax that stays out of your face, batteries included, packages for everything that&#x27;s not included. What&#x27;s Zig&#x27;s edge?

My main issue with this is I expect Mojo to become the go to tinkering language for me.

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

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 &quot;correctly&quot;.For me it is now the go-to &quot;tinker in my garage&quot; language.

After watching Andrew Kelley&#x27;s interview video makes me want to pick up Zig: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=iqddnwKF8HQ" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=iqddnwKF8HQ</a>

mainly because this build system change, along with upgrading to LLVM 22, are the only major changes for 0.17.0: <a href="https:&#x2F;&#x2F;ziglang.org&#x2F;download&#x2F;0.16.0&#x2F;release-notes.html#Roadmap" rel="nofollow">https:&#x2F;&#x2F;ziglang.org&#x2F;download&#x2F;0.16.0&#x2F;release-notes.html#Roadm...</a>

&gt; We’ll be releasing 0.17.0 within a couple weeks from now.This is amazing. Didn&#x27;t 0.16 take &gt;1 year?I was not expecting such a fast 0.17 release, but am very pleased to find this out today.

.....Did you just complain about Rust&#x27;s &quot;lower adoption&quot; compared to C++, immediately following it by &quot;Zig, on the other hand :eyes_emoji:&quot;

I don&#x27;t think Rust users are relevant here. It primarily comes down to personal preferences, and since Zig and Rust are so different, some will be drawn to Rust and others to Zig. If you really like a language and it suits your needs, be it Rust or any other, there&#x27;s no need to look to switch. I think that the audience Zig is aimed at is low-level programmers who haven&#x27;t taken a liking to Rust, which is the majority of them. Rust isn&#x27;t very popular among experienced low-level programmers (certainly for a language that old), and I guess Zig is hoping to be more to their liking.For example, I find Rust to be far too similar to C++, and it shares most of the problems I have with C++ only with much lower adoption. I&#x27;m not saying I&#x27;m ready to make the switch, but at least Zig offers a different approach that&#x27;s intriguing to me.

Try it if you want full control over every memory and IO operation and &quot;drop&quot;. If you hit &quot;goto-definition&quot;, you eventually get to see the OS switch statements and syscalls. There&#x27;s not much magic.Do not try it if you are scared of memory management and memory leaks.

Not working within the bounds of lifetimes, and more ecosystem that doesn&#x27;t live in the world of lifetimes, gives Zig some of the wonderful dev ergonomics of Rust while making it easier to prototype.For small, short game dev, or even smaller embedded projects, this ends up being a wonderful way to live as often times you&#x27;re trying to eke out performance in ways that would require breaking out of whatever type abstractions or using unsafe.For long-lived systems, for systems that need to have lots of people with various skill levels work on them, for a mature ecosystem, for a language&#x2F;standard library with stability... You probably don&#x27;t want to pick Zig right now. Some of these points will change over time with Zig becoming more mature, some won&#x27;t. Zig will always be super cool to build things in.As far as most low-level programmers not liking Rust like some other commenters say, lol, lmao even.

Would someone tell a rust user why they should and should not try zig?

I believe if the work you do fits well with Node &amp; TS, you have no reason to use zig (other than for learning or curiosity). Like, if you don&#x27;t need every drop of performance, memory layout &amp; control, there&#x27;s more downsides to using zig. Idk, cruds or &quot;enterprise&quot; stuff or websites don&#x27;t benefit from zig.

I suggest you try using Ghostty (written in Zig) for a bit and compare it to another terminal like Hyper (written in JavaScript).

What?You can&#x27;t run Node on embedded systems, because there isn&#x27;t enough memory.A compiled zig program can be only several kilobytes with no depedenencies.Array access programmed in low-level languages can be optimized with SIMD and parallelization, which will be orders of magnitude faster than the same thing on Javascript. Text processing, image manipulation, video processing, hashing, etc.There is like infinite reasons to not use Javascript.

Why would I want to use this over, say, Node.js and TypeScript?

Also another point. I have some zig projects from couple of months back and they all have build.zig&#x2F;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&#x27;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&#x27;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.

Just creating a file with dummy test likeif (2 * 2 != 5) { @panic(&quot;fail&quot;); }And running `zig test file.zig -OReleaseSafe` takes a couple seconds on my computer. It also keeps taking the same amount of time every time I do it when I modify that file. Using 0.16 (or master) version so my toolchain isn&#x27;t old and I&#x27;m on linux.Zig is super nice to use as a language but the compiler&#x2F;stdlib isn&#x27;t developed conservatively enough imo.You may not run into an issue like this when starting out with hello world but you will want to run optimized binaries for fuzz testing or benchmarking. And then it becomes super annoying considering you might be compiling a relatively small amount of code.Just for comparison, imo Zig is a much better language than these other languages, but if you did something like this in Rust&#x2F;C++&#x2F;C etc. this kind of issues basically doesn&#x27;t ever happen. Assuming clang&#x2F;gcc&#x2F;ninja etc. usage for C&#x2F;C++.I am able to use Ninja&#x2F;Python&#x2F;clang for configuring&#x2F;building (-O2 or -O3)&#x2F;testing ~10k loc C++ project in 200ms on the same computer for example.

&gt;(re)built are not what I&#x27;d describe as &quot;terrific&quot;.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.

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

&gt; Zig&#x27;s compilation times are already terrificIn my experience, this (for now) is mostly aspirational. It&#x27;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&#x27;d describe as &quot;terrific&quot;.

I thank Go for this. Go&#x27;s compilation times seemed to inspire other language devs

Yes, compilation speeds of the 90&#x27;s are slowly making a return, thankfully.

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

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 &quot;instead of That use This&quot;

There is no ETA on 1.0, but breakage has followed the pattern of it not really being hard to upgrade to a newer version, as it is very well documented on the version release notes.

nitpick: The language is pretty stable, what changes is the standard library.

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.

Andrew&#x27;s take is &quot;it&#x27;s ready when it&#x27;s ready but we hope it&#x27;s good enough before it&#x27;s fully ready that you want to use it anyway&quot;.It&#x27;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.

Is there any proposed timeline for a stable release? Big features like the recent async IO shows the language is very unstable right now.

&gt; RAII is great; I wish they&#x27;d use some light (optional) RAII for strings and containers etc.Is it not possible to build a wrapper that does this? It seems like it should be.

For me it’s string handling, no private, unused variable is compilation error, and having to implement interfaces myself.

Zig has so many compelling features, and I&#x27;d even be willing to give up Rust&#x27;s near-perfect memory safety in some cases. But the one thing that really put me off is string handling. It&#x27;s just so super tedious. I like being able to finely manage individual string memory allocations, but I really don&#x27;t want to have to do it all the time. RAII is great; I wish they&#x27;d use some light (optional) RAII for strings and containers etc.

There are a number of licenses that are named MIT that are all similar, but not identical.The &quot;Expat&quot; 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.

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

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

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

I think bun is moving to rust because Anthropic owns it and the devs there like rust. So why would they invest in another implementation? Sad to see a good zig example go, but as soon as Anthropic bought it I wrote the project off.

Bun has de-facto refused to use incremental compilation in Zig for ages. It got to the point where Jarred somehow seems to have forgotten that the feature exists.In any case Bun has already committed to the Rust slop switch, so it doesn&#x27;t matter anymore.

Somebody should revive the zig version of bun and call it banh as in the vietnamese banh mi sandwich :)

&gt; 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&#x2F;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.

I bet they&#x27;ll ultimately reverse course on this, or the there will be a bun &#x2F; zig fork becomes the de facto bun. Despite what the influencers say, I&#x27;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&#x27;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?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 is moving towards rust but does this also help bun&#x27;s compilation times?<a href="https:&#x2F;&#x2F;ziggit.dev&#x2F;t&#x2F;bun-s-zig-fork-got-4x-faster-compilation-times&#x2F;15183" rel="nofollow">https:&#x2F;&#x2F;ziggit.dev&#x2F;t&#x2F;bun-s-zig-fork-got-4x-faster-compilatio...</a>

Zig: Build System Reworked