This sounds like great news, Zig's compilation times are already terrific and this is going to only make them better.
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".
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.
if (2 * 2 != 5) { @panic("fail"); }
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't old and I'm on linux.
Zig is super nice to use as a language but the compiler/stdlib isn'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/C++/C etc. this kind of issues basically doesn't ever happen. Assuming clang/gcc/ninja etc. usage for C/C++.
I am able to use Ninja/Python/clang for configuring/building (-O2 or -O3)/testing ~10k loc C++ project in 200ms on the same computer for example.
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.
> 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
Edit: I just realised you have a compilation error so the compiler isn't doing much work
Every single new post-Go language, like Rust & Zig, ships with an opinionated autoformatter and a single go-to command to manage builds, packaging, etc.
And how many new languages do you see include inheritance and exceptions?
Older languages have started adapting what they can too:
- Python with `uv` and `black`
- Java with goroutine-like fibers and modern configuration-free gcs and the go-gc-like low pause times zgc
- Many languages now ship a production-ready http server, just like Go
From type theory exceptions are effects, and result types are a form of effects.
Auto formatting has been a thing in IDEs for a decade, and doing pre-commit hooks on CVS with indent was a thing in the 1990's.
Java and .NET had http servers.
Co-routines trace back to languages like Solo Pascal.
Configuration free GC not really that great, given the rewrites into Rust.
Anyway, Oberon, Modula-3, Eiffel, .NET,....
Pauseless GC goes back to real time Java from PTC, Aonix, Aicas, and companies like Azul with their custom hardware.