My question would have been, why is the IR flat. That intuitively seems harder to optimize and work with, to me. - I know Kotlin uses tree IR, and that just makes sense to me. (tree IR is quite different from AST, of course)
There was a talk from the Go team where they mentioned about supporting exotic architectures. Any one who wanted to implemented a new target GOOS, GOARCH, they could implement that translation layer GOASM -> machine code and bam! support for a new target. And according to them, the translation layer is simple.
The problem with Zig is documentation. I can see that goes for the code as well...this needs to get way better. Maybe the Foundation can hire someone to write documentation?
Honestly, it hasn't been much trouble for me. Once you understand the syntax and are aware of the conventions (which there aren't too many anyways), the code becomes its own documentation. Which I imagine is part of the objective of Zig.
There is no need for that. If your compiler has AST nodes that it understands, it can implement their behavior as C++ functions and then modify the AST with the results
@@darkfllame If I recall correctly, Andrew mentioned that first compiler converts the source code to untyped IR. Then at some later stage untyped IR is converted to typed IR. I was wondering why not directly start with typed IR as the code author already declares the variable types. As you can tell I'm a compiler noob. If this is something obvious please let me know I'll do more research
I think Andrew was just referring to the comptime approach that they implemented. I'm not certain that what he described here still holds true today though. The video here is almost 4 years old, back when Zig was at 0.6.0.
Held my curiosity for a while, but the technical issues made it unbearable to watch. All the flickering, and Andrew talking about code that's not loaded on the screen yet... quite a mess. From Andrew's other talks, I can tell that he's a great speaker, but for this video in particular, it's getting a thumbs down from me. Would love to see a re-take though.
You're probably not missing anything, it's still not all that mature. It's an interesting language and I'm playing with it, and I think it has a brighter future -- but if you want to solve an actual problem right now today, there are other languages that are good enough and which have much better library support. For systems and embedded you're probably making smaller programs and so the lack of libraries is less of a problem, but you'll still get up and running faster with existing frameworks in C/C++ or even Rust, so if you're being paid to do the work you might choose one of those.
