Jon Blow gave a talk at LambdaConf and showed of Jai. The interesting bit for me was this part on program visualization. I linked to the timestamp for this discussion.
The benefits are visible (pun intended). Being able to quickly see function size, comptime expansion, etc. would be really helpful. Obviously this would require instrumenting the compiler to emit these kinds of metrics, but I wonder what this would look like for Zig or even a tool for programming languages in general.
zig is planning to have the compiler be able to output lots of information as a server for tools to use. Could be used to make such visualisations.
I remember seeing someone make a network graph for zig using zls
I watched this talk! I remember thinking the whole time, “this is all stuff that would be built into a good IDE”.
It seemed like some of that data would be hard for an external tool to gather? Maybe you already have ideas on this, but I’m not sure how an IDE would easily and reliably track functions and correlate them to an AST tree for example? It was pretty cool to see that visual which showed how much affect generic instantiation had on the binary size.
Compiling 300k+ loc in 2 seconds without incremental compilation ans with an LLVM is kinda nuts. I wonder what they do differently than zig.
I believe they have a self-hosted x86_64 backend for debug builds as well. It must be written in C++ though, since the compiler itself isn’t self-hosted.
The main problem in Zig is that we have too much comptime code duplication. Starting with data structures (and in the talk he briefly shows what seems like some code deduplication of hashmap instantiations in Jai), but the problem is deeper, since we have many regular functions that get duplicated at comptime, like the formatting (in my opinion a comptime format string was a bad decision) and even allocators (those functions only care about size and alignment, so we do we need separate instances for individual types?).
Overall it all kind of comes back to the visualization. If we had an easy tool to visualize compilation complexity, then we’d have a chance to see and fix these problems. As far as I’m aware there are also some instances of ridiculously large single functions in the binary, particularly in std.crypto.
One possible solution would be to extend LSP protocol to have this sort of information. Or come up with another option like DAP is separate but provides a similar api. If the tools can expose these metrics in a compiler agnostic way, that could fit the bill here. Although if we are doing a new api, I hope we can avoid JSONRCP.
I just assumed that in the context of Zig #615 could also give detailed information about compiled functions and AST / other related statistics.
This kind of thing is what I meant when I said that LSP is a bad protocol and that Zig’s compiler server will be more powerful, with a LSP being a third party proxy.
https://m.youtube.com/watch?v=c5LOYzZx-0c here’s another!