17 Likes
So glad to hear from Andrew again!
2 Likes
Are these all things that conceivably could be accomplished in 2024, or just what the plan looks like as of 2024?
1 Like
The latter.
2 Likes
I saw the interview and had a question and a remark.
Regarding incremental compilation, don’t other languages already have that? For example in C and C++, after a full build, modifying a source file would only just recompile the source file modified. Modifying a header would cause every source file including it to recompile.
Regarding async/await, Rust does its code transformation in the frontend, i.e it doesn’t use llvm’s coroutines. As for llvm’s implementation (which AFAIR is 7 years ongoing now, since llvm 4), I think it’s Gor Nishanov who’s behind them in both llvm and msvc, he’s also the driver behind the standardization of coroutines in C++. Gor also claims a negative-overhead from it. llvm’s documentation explains how it’s possible to avoid heap allocation. It would be interesting to know more of their shortcomings rather than just calling it trash!
2 Likes
C/C++ “incremental compilation” is kind of fake. It relies on creating a different compilation unit for each file, and linking the object files together in the end. This is not really great. If you for example change a header file that is included everywhere, you end up having to recompile everything. Additionally the linking step quickly becomes a bottleneck.
By the way from what I have seen Zig already supports this kind of incremental compilation. You can, if you want, compile code into different object files and link them together.
I think what Andrew is talking about here is incremental compilation at the function level. So if you update one function in a file it will only update this one function and it’s dependents and nothing more. Additionally I think the plan is to have linker level support, so the linker only needs to update a small part of the entire binary instead of regenerating it completely.
9 Likes
At the function level, it sounds more like incremental linking:
Binary patching and incremental linking has been available with Gold, msvc’s LINK.
1 Like
Correct, and this is what Zig will offer too - in-place binary patching. Additionally, we will serialize the state of the compiler (and linker) so that when you come back to your project, you will be able to resume where you left off without having to recompile and relink the entire project. Finally, all of this is also a prelude to in-built hot-code reloading support.
18 Likes
Video transcript extracted and edited by AI. Not the whole video, just the part where Andrew speaks.
Title: An Exclusive Interview with Andrew Kelley, Creator of the Zig Programming Language
Introduction: In this interview, Andrew Kelley, the creator of the Zig programming language, shares exclusive updates and insights regarding the upcoming release and future plans for Zig. He discusses the importance of addressing critical third-party projects, fixing bugs, improving compiler performance, and implementing incremental compilation. Additionally, Andrew reveals details about financing the Zig Software Foundation (ZSF) and reaching the elusive 1.0 milestone.
Upcoming Release Details: To access the latest information about the upcoming Zig release, visit the Zig GitHub page and navigate to the “Milestones” tab. The current milestone focuses on completing specific tasks rather than adhering to a strict deadline. This approach allows developers to concentrate on delivering essential features before tagging a release. By visiting the tracking issue, community members can add their projects to the list of important third-party projects, ensuring compatibility and support.
Post-Release Roadmap: After the release, the primary focus will shift to addressing bugs and enhancing compiler performance. With over 1,200 reported bugs, solving more than one per day is crucial. To achieve this, reducing compile times is essential. Faster compile times enable developers to spend less time waiting and more time testing and editing code, leading to quicker bug resolution.
Incremental Compilation: The cornerstone of Zig’s future development is incremental compilation—a unique feature among programming languages. Although not yet implemented, significant resources have been invested in preparing the necessary infrastructure. Once completed, incremental compilation will provide dramatic improvements in productivity for game development, terminals, JavaScript engines, databases, and other resource-intensive applications. Moreover, the Zig compiler team will benefit significantly from this feature, allowing them to address bugs more efficiently.
Financial Support for ZSF: Andrew discussed ZSF’s funding challenges, emphasizing the need for additional financial support to accelerate development. Currently, individual contributions account for approximately a third of ZSF’s total income. Increased monetary support from both individuals and organizations would enable ZSF to hire more contractors and expedite the journey toward 1.0.
Reaching 1.0: As Zig approaches 1.0, several key objectives must be addressed.
- Performance improvement: Making the compiler faster remains the most effective path to achieving 1.0. Enhanced compiler performance translates to improved development velocity.
- Language adaptability: As the language evolves, adjustments may be needed to accommodate desired compiler optimizations. These alterations aim to strike a balance between language constraints and compiler efficiency.
- Standard Library enhancement: Solidifying the standard library involves refining and stabilizing existing components while adding missing elements. This process ensures consistent quality across the board.
Despite the significance of the 1.0 milestone, Andrew encourages users to embrace Zig before this point, as real-world usage helps identify and resolve potential issues early on. Furthermore, he suggests introducing version declarations within the source code to facilitate seamless integration between different versions of the language.
Q&A Session:
During the Q&A session, participants raised concerns about topics such as async functionality, tooling, internal compiler changes, and contributor engagement. Here are some highlights:
- Async functionality: While acknowledging the appeal of async programming, Andrew explained that integrating it into Zig presents numerous technical challenges. Implementing custom code generation backends and debugging tools are among the obstacles requiring solutions before async becomes practical in Zig.
- Tooling: Addressing questions about tooling, including language servers and documentation generators, Andrew confirmed that certain aspects of Zig’s tooling are robust, whereas others remain under development. However, the team is committed to continuous improvement and welcomes community involvement.
- Internal compiler changes: Discussing the intern pool changes, Andrew described the extensive nature of the modifications and assured users that thorough testing prevented unexpected issues during implementation.
- Contributions: Encouraging prospective contributors, Andrew provided guidance on engaging with the project, noting that submitting Pull Requests is an excellent way to suggest alternative directions and improve overall development velocity.
3 Likes
Thanks for uploading a translation @undefined - for some people the audio could be a bit tough to follow. The one thing I’d say here is that he mentioned that it was an interesting idea (and he thinks they could have done more with this in python), but he’s primarily saying that it’s one possible approach.
Otherwise, pretty good 
2 Likes
Andrew Kelley’s opening:
“Hey everyone, my name is ginger bill, i’m the creator of the odin language and please try my new beer. just kidding”
I don’t understand what happened here. Anyone knows what was meant by this?
1 Like
Well, gingerbill is the handle of Odin programming language creator Bill Hall, who recently started a brewery business. So that should explain the confusing beer bit for ya 
2 Likes
Alright! now, it makes sense. Although I can’t find anything online; I will just take your word for it.
You can catch up by watching his chat with Abner at Handmade Seattle 2023:
1 Like
Hey @kubkon , easy on the heap of jaw-dropping killer features in a single post man! You’re gonna give people a heart attack. lol
3 Likes
This is a great business idea to help fund Zig development. Zig-beer (Zeer) or Zoffee caffeinated beverage, anyone? Proceeds go directly to ZSF.
4 Likes
Question: Can we have a couple of words about async?
timestamp: https://youtu.be/5eL_LcxwwHg?t=1842
Paraphrased:
Andrew explains that it currently isn’t practical, because there are a lot of difficult problems, that are in the way of a good implementation of async, these other things need to be addressed first.
Summary
And I tried to transcribe the summary in the video:
timestamp of async/await summary
Ultimately, I think it can be recovered, I think we can have async/await.
But it is just an extremely difficult technical problem to solve and I am not willing to solve it in a half-assed way.I don’t wanna just check an async/await box, it’s gotta be good.
Let me do it on my own time, we will get there, but there is just multiple huge technical problems to solve, to make it actually good.
8 Likes
As a newcomer to Zig - I have now enough understanding to know what Zig is about, its patterns, its shortcomings, what it does well and what it isn’t - from a technical perspective anyway.
I am not using it in production or preproduction yet - basically sideline projects to get to grips with Zig. I am in a very small company with a weak currency/exchange rate - so any contributions I can make will not change anybody’s life.
So to the point - what is the future of Zig? What happens if the author tomorrow decide to quit? I have no issue with the technical roadmap - I have an issue investing time in something which does not have at least a short foreseeable (3 year?) contingency.
I am not saying that Zig does not have contingency - I would like to know if there is a plan, who “drives/owns” it and what its forecast(s) are - not technically, but business wise?
The fundamental thing here is that there’s a lot more uncertainty around Zig than around C++ or Rust. If you can’t tolerate uncertainty, then that’s not the right time to look at Zig. Every release notes document ends with
Working on a non-trivial project using Zig may require participating in the development process.
The way I see it, from the perspective of a TigerBeetle developer:
- There’s a good measure of institutional continuity in place. There’s Zig Software Foundation, which is an impersonal institution with a funding structure and a goal of furthering Zig development. This is actually more institutional continuity than, e.g., Rust had most of its lifetime, as was demonstrated by Mozilla layoffs.
- I personally think that not only institutions, but specific people are very important for the “taste” of technical projects. But this is not unique to Zig, and, looking at Guido van Rossum, Anders Hejlsberg, or Bjarne Stroustrup, it looks like language designer is not a profession prone to early retirement.
- For my use-case, Zig also is more or less finished language. There’s a bunch of rough edges still to sand off, and a lot of “numeric” improvements to be had yet (can’t have enough compilation speed), but there’s nothing big in the future that would determine suitability of Zig for the use-case of writing databases. Language-level uncertainty is mostly already realized, with the exception of async (but we don’t use and don’t plan to use async in our codebase) or aliasing guarantees (which is theoretically nasty, but doesn’t seem to be a huge problem in practice).
- That coupled with the fact that Zig is a small and simple project, means that even in the doom&gloom scenario where the entire core team decides that systems programming is not where it is at, and switches to developing a novel JIT compiled dynamically typed logical programming language, it wouldn’t be a prohibitive amount of effort to maintain the language at its current level.
12 Likes
That coupled with the fact that Zig is a small and simple project, means that even in the doom&gloom scenario where the entire core team decides that systems programming is not where it is at, and switches to developing a novel JIT compiled dynamically typed logical programming language, it wouldn’t be a prohibitive amount of effort to maintain the language at its current level.
I’m very interested to see if any alternate Zig implementations start popping up. That’d be a big step in wide Zig adoption, at least in my part of the software ecosystem. Hardware people looking at Zig instead of C for baseline HAL stuff would make it basically unkillable.