How far away is 0.11 really?

Some time ago 0.11 was planned with LLVM 16 release, then some time recently it was said that it’d be postponed until the end of June.

Now looking at the state of 0.11.0 Milestone · GitHub it feels it’s still very far off.

I get that these things are hard to estimate, and I totally get the delays. My question is really just to manage my own expectations, as I’ve been looking forward to incremental builds for quite a while, but I haven’t heard any updates on this recently, so not sure if I should be holding my breath, or if it’s one of those “we’re still probably a few months away”.

I don’t mind either way, but it just feels that 0.11 might be a bit further away than was expected. Which again is fine, I’m just trying to understand the state of things.

I’m also curious about the state of hot code swapping. Last time I saw there were working prototypes of HCS with the new compiler on all platforms, and it was kinda like “this will land together with the incremental builds and stuff”, but haven’t heard much about it since, so again just wanted to check if it’s something to look forward to any time soon, or if it’s one of those “we’ll get it when we get it, but not any time soon” features?

2 Likes

Incremental builds are definitely at least a few months away still. For that to work we need:

  • custom backends with 100% test coverage for each arch (current state: some backends pass ~60% of the tests)
  • linker support for each OS

If you’re on x86_64 Linux chances are that you will be able to access incremental compilation than other arch+os combos, but it will still take a while.

Hot code reload needs incremental to work first so, realistically speaking, you should not expect hot code reload to land in 2023.

What you’re seeing is mostly the difference between a PoC and actually doing the thing correctly for the entire problem space (arches, OSs, linking with C/C++ code, etc), and partially the fact that right now development effort is also being spent in other directions (eg the package manager).

Don’t be ashamed to ask for status updates, the Zig roadmap doesn’t have any burn down chart with deadlines on it, but I and other people in the core team have a general sense of where we’re at, and we’ll always be happy to tell you what’s going on in the project. As long as the polling is not too frequent :^)

Also happy to expand more in case you have more questions.

9 Likes

Oh, I almost forgot: 0.11 is being delayed to make sure async/await support is restored in the compiler, so AFAIK that’s the main blocker for the release.

10 Likes

Thanks for replying and the detailed info! Though I have to admit I’m a little sad by the incremental builds being so far away :frowning:

I’m not sure if I’m just not using Zig wrong, or maybe others don’t really mind this, but for example I looked at https://bun.sh/ which is written in Zig, and when I change 1 line of code and run a rebuild it takes 2.5 minutes on my 24 core 64GB RAM Linux desktop.

Is this currently expected? I’ve seen some people say “compile times are great, much better in Rust”, but … maybe those people are just writing very small projects? Or am I doing something fundamentally wrong?

It’s not 2.5 mins in my project but I also find builds pretty slow. I’m working on a little game which is not a whole lot of code, but every recompile-test cycle is like 20 secs. This would be less than 1s for an equivalent incremental C build. Combined with ZLS missing a lot of mistakes in my code (due to known limitations), iterating on code can be a little slow.

I’m also very much looking forward to incremental builds. :slight_smile:

and when I change 1 line of code and run a rebuild it takes 2.5 minutes on my 24 core 64GB RAM Linux desktop.
Is this currently expected?

There is no incremental compilation at all at the moment. Every time you make a change you’re rebuilding the full Zig codebase, including all parts of the stdlib that Bun uses. Bun also makes very heavy use of comptime, which re-runs from scratch every time.

Once incremental compilation is implemented things should improve.

4 Likes

It’s time to focus on the release for sure. There are only 2 things left that will prevent from releasing on time:

  • if async/await is not done yet
  • if the release notes are not done yet

Everything else can be postponed to 0.12.0 or 0.11.1.

I may need 1-2 more weeks past June 30th to finish these two important things, but I don’t expect to postpone any longer than that.

I do apologize for the big delay on this one - it really just came down to the fact that I really, really wanted to work on some other stuff than the release, when the release was coming up. And I allowed myself to do that. As a result, we have some nice things we wouldn’t otherwise, and the release is delayed by 1.5 months from the originally planned date.

14 Likes

I’m glad you guys are taking your time - I became a paid supporter of Zig via github because I liked how little baggage the language has and how skeptical you guys are (justifiably so) of adding piles of syntactic sugar. I (for one) say take your time… especially with async and await given that these things directly interact with keywords… gotta get those right.

Speaking of which, have you guys looked into the work of Eric Niebler at all? He’s the guy that got ranges into the C++ standard library, but he had a lot of really interesting takes on lazy evaluation and multi threading. Just curious.

7 Likes

ETA is Aug 3rd… Get pumped!

4 Likes

w/o async though, but oh well.
I prefer things done properly to things done quick and dirty way.

3 Likes