I watched the linked talk by Andrew Kelly - super interesting stuff. I've played a bit with data oriented design in the context of implementing an ECS, but some of the topics he discusses take it to another level entirely, and it's very cool to see it applied, with measurable results, in a large serious project like a compiler.
I have a lot of admiration for Zig, as I think it takes a very interesting approach to being a "better C", and the no-nonsense approach, ruthless simplicity, and thin abstraction over the hardware fall very much in line with my values as a programmer.
As a product manager, a few thoughts ran through my head when when I was watching this: with where Zig is as a language, is this kind of focus on extreme memory optimization actually the best use of his time?
There's an argument that it might be: maybe this is an exercise in dogfooding Zig as the kind of language which is suitable for data oriented design. Or it could be Kelly has fallen victim to the temptation many of us do, in following the most fascinating path rather than the one that's creating the most long lasting value.
Either way I guess that's a luxury he has the right to indulge as an independently funded auteur PL designer.
The choice of improving the performance of the compiler before working on the package manager was deliberate. With the new compiler you will be able to have plenty of dependencies and compilation times / memory usage will remain reasonable. The same could not be said of the bootstrap compiler.
For us compilation speed is part of the main value offering of Zig.
Is this working? stage2 seems to take similar and large amounts of time to compile a non-async-using program from our project with no caches and with caches after a whitespace change.
The linked post mentioned that the compiler itself does compile faster, but not by much. Memory usage is the greatest impact of stage2.
The speed will come when the native backends are finished. Right now the compile time is mostly llvm. The idea is a native and fast backend for debug (development) builds, and llvm for optimized releases.
Well, while you are developing a language, in particular a system programming language like zig, having to write your compiler in zig is a great way to learn first hand what your users are complaining about. Normally if you dogfood your own creations, you experience them maybe an hour a day, but the compiler will be the number one tool when working on zig.
As a compiler engineer myself, I dislike dogfooding in the compiler itself. It biases us to design the language for the compiler use case, and that is in fact a very niche use case. I much prefer having a side project that uses the language I'm implementing, instead of using it to implement the compiler itself.
On that note Andrew started a side project recently using Zig, and has already written a bunch of useful notes from the user's POV. I'm certain he'll make that public soon enough.
I have a lot of admiration for Zig, as I think it takes a very interesting approach to being a "better C", and the no-nonsense approach, ruthless simplicity, and thin abstraction over the hardware fall very much in line with my values as a programmer.
As a product manager, a few thoughts ran through my head when when I was watching this: with where Zig is as a language, is this kind of focus on extreme memory optimization actually the best use of his time?
There's an argument that it might be: maybe this is an exercise in dogfooding Zig as the kind of language which is suitable for data oriented design. Or it could be Kelly has fallen victim to the temptation many of us do, in following the most fascinating path rather than the one that's creating the most long lasting value.
Either way I guess that's a luxury he has the right to indulge as an independently funded auteur PL designer.