So glad to hear from Andrew again!
Are these all things that conceivably could be accomplished in 2024, or just what the plan looks like as of 2024?
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!
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.
At the function level, it sounds more like incremental linking:
Binary patching and incremental linking has been available with Gold, msvc’s LINK.
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.
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.
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.
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.
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
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?
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
Alright! now, it makes sense. Although I can’t find anything online; I will just take your word for it.
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
This is a great business idea to help fund Zig development.
Zoffee caffeinated beverage, anyone? Proceeds go directly to ZSF.
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.
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.