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".
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.
> 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
Granted I'm on an M4 Mac but I wouldn't expect another system to be 20x slower.
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.
Pascal has a lot of influence on this, but Go as well! My PL friends often talk about Go's benefits and flaws when thinking about advancing other their own projects or improving the mainstream languages they work on.
Go changed something, not sure if 20 or 21, where it will download the Go compiler of all your third-party which don’t match yours. It slows things down.
> Zig's compilation times are already terrific
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".
>(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?
I foresee a pjmlp comment in your near future. :)
Oh that is me as well :)
Yeah, let's add a sprinkle of toxicity to my Saturday morning!
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. 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.
> 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):
Granted I'm on an M4 Mac but I wouldn't expect another system to be 20x slower.I’m on ryzen 7600 cpu and linux cachyos.
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.
To be fair the language is in beta and breaking changes are expected.
Yes, compilation speeds of the 90's are slowly making a return, thankfully.
I thank Go for this. Go's compilation times seemed to inspire other language devs
I doubt Go has any sizable effect on the community of programming language developers. Probably Pascal has more impact on this.
Pascal has a lot of influence on this, but Go as well! My PL friends often talk about Go's benefits and flaws when thinking about advancing other their own projects or improving the mainstream languages they work on.
Go changed something, not sure if 20 or 21, where it will download the Go compiler of all your third-party which don’t match yours. It slows things down.
Yeah, not a fan of the idea that now the standard library is distributed as source code and packages are compiled on demand.
Note D as another example, and it predates Go.