This could be the greatest programming language development of the last 10 years. Finally a language that compiles fast and is fast at runtime too.
Retro_Dev · 6h ago
As far as I know, Zig has a bunch of things in the works for a better development experience. Almost every day there's something being worked on - like https://github.com/ziglang/zig/pull/24124 just now. I know that Zig had some plans in the past to also work on hot code swapping. At this rate of development, I wouldn't be surprised if hot code swapping was functional within a year on x86_64.
The biggest pain point I personally have with Zig right now is the speed of `comptime` - The compiler has a lot of work to do here, and running a brainF** DSL at compile-time is pretty slow (speaking from experience - it was a really funny experiment). Will we have improvements to this section of the compiler any time soon?
Overall I'm really hyped for these new backends that Zig is introducing. Can't wait to make my own URCL (https://github.com/ModPunchtree/URCL) backend for Zig. ;)
sali0 · 5m ago
URCL is sending me down a rabbithole. Haven't looked super deeply yet, but the most hilarious timeline would be that an IR built for Minecraft becomes a viable compilation target for languages.
AndyKelley · 5h ago
For comptime perf improvements, I know what needs to be done - I even started working on a branch a long time ago. Unfortunately, it is going to require reworking a lot of the semantic analysis code. Something that absolutely can, should, and will be done, but is competing with other priorities.
lenkite · 1h ago
Thank you for working so hard on Zig. Really looking forward to Zig 1.0 taking the system programming language throne.
9d · 4h ago
Have you considered hiring people to help you with these tasks so you can work in parallel and get more done quicker?
AndyKelley · 4h ago
It's a funny question because, as far as I'm aware, Zig Software Foundation is the only organization among its peers that spends the bulk of its revenue directly paying contributors for their time - something I'm quite proud of.
9d · 3h ago
Oh so then you're already doing that. Well then that's fine, the tasks will get done when they get done then.
bgthompson · 6h ago
Hot code swapping will be huge for gamedev. The idea that Zig will basically support it by default with a compiler flag is wild. Try doing that, clang.
Retro_Dev · 6h ago
Totally agree with that - although even right now zig is excellent for gamedev, considering it's performant, uses LLVM (in release modes), can compile REALLY FAST (in debug mode), it has near-seamless C integration, and the language itself is really pleasant to use (my opinion).
dnautics · 1h ago
Is it easy to build out a custom backend? I haven't looked at it yet but I'd like to try some experiments with that -- to be specific, I think that I can build out a backend that will consume AIR and produce a memory safety report. (it would identify if you're using undefined values, stack pointer escape, use after free, double free, alias xor mut)
ww520 · 3h ago
Is comptime slowness really an issue? I'm building a JSON-RPC library and heavily relying on comptime to be able to dispatch a JSON request to arbitrary function. Due to strict static typing, there's no way to dynamically dispatch to a function with arbitrary parameters in runtime. The only way I found was figuring the function type mapping during compile time using comptime. I'm sure it will blow up the code size with additional copies of the comptimed code with each arbitrary function.
Okx · 2h ago
Yes, last time I checked, Zig's comptime was 20x slower than interpreted Python. Parsing a non-trivial JSON file at comptime is excrutiatingly slow and can take minutes.
bgthompson · 6h ago
This is already such a huge achievement, yet as the devlog notes, there is plenty more to come! The idea of a compiler modifying only the parts of a binary that it needs to during compilation is simultaneously refreshing and totally wild, yet now squarely within reach of the Zig project. Exciting times ahead.
9d · 5h ago
> For a larger project like the Zig compiler itself, it takes the time down from 75 seconds to 20 seconds. We’re only just getting started.
Excited to see what he can do with this. He seems like a really smart guy.
What's the package management look like? I tried to get an app with QuickJS + SDL3 working, but the mess of C++ pushed me to Rust where it all just works. Would be glad to try it out in Zig too.
WalterBright · 2m ago
The dmd D compiler can compile itself (debug build):
real 0m18.444s
user 0m17.408s
sys 0m1.688s
On an ancient processor (it runs so fast I just never upgraded it):
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
stepping : 2
cpu MHz : 2299.674
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
stratts · 3h ago
Package management in Zig is more manual than Rust, involving fetching the package URL using the CLI, then importing the module in your build script. This has its upsides - you can depend on arbitrary archives, so lots of Zig packages of C libraries are just a build script with a dependency on a unmodified tarball release. But obviously it's a little trickier for beginners.
Zig makes it really easy to use C packages directly like this, though Zig's types are much more strict so you'll inevitably be doing a lot of casting when interacting with the API
LAC-Tech · 1h ago
It's also worth pointing out that the Zig std library covers a lot more than the rust one. No need for things like rustix, rand, hashbrown, and a few others I always have to add whenever I do rust stuff.
nindalf · 1h ago
You add hashbrown as an explicit dependency? The standard library HashMap is a re-export of hashbrown. Doesn’t it work for you?
vlovich123 · 1h ago
Can’t speak for the op but there’s a number of high performance interfaces that avoid redundant computations that are only available directly from hashbrown.
LAC-Tech · 1h ago
huh, does it? I always add it so I can make non-deterministic hashmaps in rust. oh and you need one more one for the hashing function I think.
But I did not know hashmap re-exported hashbrown, thanks.
throwawaymaths · 37m ago
im stunned that zig can compile itself in 75 seconds (even with llvm)
foresto · 1h ago
Isn't this one of the preconditions for bringing async/await back to Zig?
I've got that stuff all figured out, should have some interesting updates for everyone over the next 2-3 months. Been redoing I/O from the ground up - mostly standard library work.
geodel · 1h ago
Reading the link, it seems to me async is never coming back or at least not till 2028.
mirekrusin · 3h ago
Sounds like Julia should consider switching to Zig to get considerable performance gains. I remember authors feeling uneasy with each llvm release worrying about performance degradations.
jakobnissen · 14m ago
That could be a way to get compile times down, but I think there is still much to do on the Julia side.
Such as a more fine grained compile cache, better tooling to prevent i validations, removal of the world splitting optimisation, more use of multithreading in the compiler, automatic precompilation of concrete signatures, and generation of lazier code which hot-swaps in code when it is compiled.
patagurbon · 47m ago
Julia is effectively hard locked to LLVM. Large swathes of the ecosystem rely on the presence of LLVM either for intrinsics, autodiff (Enzyme) or gpu compilation. Nevermind Base and Core.
The compiler is fairly retargetable, this is an active area of work. So it’s maybe possible in the future to envision zig as an alternative compiler for fragments of the language.
bobbylarrybobby · 1h ago
Isn't LLVM considered part of Julia’s public API? You've got macros like @code_llvm that actually give you IR
WhereIsTheTruth · 17m ago
I said it for D and Nature, and every other languages that comes with its own backend, we all have a duty to support projects that tries to not depend on LLVM, compiler R&D has stagnated because of LLVM, far too many languages chose to depend on it, far too many people don't value fast iteration time, or perhaps they grew to not expect any better?
Fast iteration time with incremental compilation and binary patching, good debugging should be the expectation for new languages, not something niche or "too hard to do"
treeshateorcs · 7h ago
so, a helloworld program (`zig init`) is 9.3MB compiled. compared to `-Doptimize=ReleaseSmall` 7.6KB that is huge (more than 1000 times larger)
AndyKelley · 6h ago
Indeed, good observation. Another observation is that 82% of that is debug info.
-OReleaseSmall -fno-strip produces a 580K executable, while -ODebug -fstrip produces a 1.4M executable.
I don't recall whether it supports stepping through comptime logic at the moment; that was something we discussed recently.
treeshateorcs · 14m ago
is it naive to expect the new backend to release -OReleaseSmall binaries as small as llvm in the future?
VWWHFSfQ · 4h ago
I'm interested in Zig but kind of discouraged by the 30 pages of open issues mentioning "segfault" on their Github tracker. It's disheartening for a systems programming language being developed in the 21st century.
enbugger · 39m ago
Since when segfaults are declared as the thing of the 20th century?
AndyKelley · 4h ago
I see 40 pages in rust-lang/rust. Are you sure this heuristic is measuring what you think it's measuring?
VWWHFSfQ · 4h ago
Oh I wasn't comparing to Rust. But just a quick glance between the two repos shows a pretty big difference between the nature of the "segfault" issues reported.
Every mature compiler (heck, project of any kind) has thousands of bugs open. It’s just a poor metric.
9d · 3h ago
That's about size and popularity, not maturity.
Several very popular, small, mature projects have zero or few open issues.
(And several mature, huge and unpopular ones too.)
VWWHFSfQ · 3h ago
Yep and like I said, I'm interested in Zig. But it's still somewhat discouraging as a C replacement just because it seems to still have all the same problems but without the decades of tools and static analyzers to help out. But I'm keeping an eye on it.
Retro_Dev · 14m ago
It is my opinion that even if Zig were nothing more than a syntactical tweak of C, it would be preferable over C. C has a lot of legacy cruft that can't go away, and decades of software built with poor practices and habits. The status-quo in Zig is evolving to help mitigate these issues. One obvious example that sets Zig apart from C is error handling built into the language itself.
ArtixFox · 3h ago
Im pretty sure valgrind and friends can be used in zig.
Zig is still not 1.0, theres not much stability guarantees, making something like Frama-C, even tho it is possible is simply going to be soo much pain due to constant breakages as compared to something like C.
Beyond that, tools like antithesis https://antithesis.com/ exist that can be used for checking bugs. [ I dont have any experience with it. ]
stratts · 3h ago
What's the state of the art here?
Most of Zig's safety, or lack thereof, seems inherent to allowing manual memory management, and at least comparable to its "C replacement" peers (Odin, C3, etc).
ArtixFox · 3h ago
I guess formal verification tools? That is the peak that even rust is trying to reach with creusot and friends. Ada has support for it using Spark subset [which can use why3 or have you write the proofs in coq]
Frama-C exists for C.
Astree exists for C++ but i dont think lone developers can access it. But it is used in Boeing.
garbagepatch · 1h ago
No shame in waiting until 1.0. There's other production ready languages you can use right now so you can ignore Zig until then.
9d · 4h ago
> And we’re looking at aarch64 next - work that is expected to be accelerated thanks to our new Legalize pass.
afaict its a new pass that transforms Air generated from Sema into Air understood by a particular backend, since theyre not all at the same level of maturity
The biggest pain point I personally have with Zig right now is the speed of `comptime` - The compiler has a lot of work to do here, and running a brainF** DSL at compile-time is pretty slow (speaking from experience - it was a really funny experiment). Will we have improvements to this section of the compiler any time soon?
Overall I'm really hyped for these new backends that Zig is introducing. Can't wait to make my own URCL (https://github.com/ModPunchtree/URCL) backend for Zig. ;)
Excited to see what he can do with this. He seems like a really smart guy.
What's the package management look like? I tried to get an app with QuickJS + SDL3 working, but the mess of C++ pushed me to Rust where it all just works. Would be glad to try it out in Zig too.
real 0m18.444s user 0m17.408s sys 0m1.688s
On an ancient processor (it runs so fast I just never upgraded it):
cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping : 2 cpu MHz : 2299.674 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes
SDL3 has both a native Zig wrapper: https://github.com/Gota7/zig-sdl3
And a more basic repackaging on the C library/API: https://github.com/castholm/SDL
For QuickJS, the only option is the C API: https://github.com/allyourcodebase/quickjs-ng
Zig makes it really easy to use C packages directly like this, though Zig's types are much more strict so you'll inevitably be doing a lot of casting when interacting with the API
But I did not know hashmap re-exported hashbrown, thanks.
https://github.com/ziglang/zig/wiki/FAQ#what-is-the-status-o...
Such as a more fine grained compile cache, better tooling to prevent i validations, removal of the world splitting optimisation, more use of multithreading in the compiler, automatic precompilation of concrete signatures, and generation of lazier code which hot-swaps in code when it is compiled.
The compiler is fairly retargetable, this is an active area of work. So it’s maybe possible in the future to envision zig as an alternative compiler for fragments of the language.
Fast iteration time with incremental compilation and binary patching, good debugging should be the expectation for new languages, not something niche or "too hard to do"
-OReleaseSmall -fno-strip produces a 580K executable, while -ODebug -fstrip produces a 1.4M executable.
zig's x86 backend makes for a significantly better debugging experience with this zig-aware lldb fork: https://github.com/ziglang/zig/wiki/LLDB-for-Zig
I don't recall whether it supports stepping through comptime logic at the moment; that was something we discussed recently.
yikes... https://github.com/ziglang/zig/issues/23556
Several very popular, small, mature projects have zero or few open issues.
(And several mature, huge and unpopular ones too.)
Zig is still not 1.0, theres not much stability guarantees, making something like Frama-C, even tho it is possible is simply going to be soo much pain due to constant breakages as compared to something like C.
But it is not impossible and there have been demos of refinement type checkers https://github.com/ityonemo/clr
Beyond that, tools like antithesis https://antithesis.com/ exist that can be used for checking bugs. [ I dont have any experience with it. ]
Most of Zig's safety, or lack thereof, seems inherent to allowing manual memory management, and at least comparable to its "C replacement" peers (Odin, C3, etc).
Sorry, what?