The cool thing that zig comptime does is that it interacts with the type system. This seems geared around computations, more than e.g. defining structs.

Fascinating.

There are some other interesting repos from the same author, namely https://github.com/pijng/goinject, which lets you inject code as part of preprocessing. Feels a lot like Java’s annotation magic.

Thanks for sharing. I wasn’t even aware Go had pre-processors, or that modifying the AST like that is even possible.

This is just integrated codegen into the build tool, right? Datadog has a similar project here https://github.com/DataDog/orchestrion that does the same thing.

I think this kind of code gen is very wonky, and hard to debug unless there is some official API support for it. Using a sufficiently advanced build tool to handle this in a separate build step would help as well. But that usually causes problems with IDE support.

Yeah, this reminds me a lot of similar practices in the JVM world with compile time annotation processors.

Bugs in those systems are hell to trace.

Coming to the Go world of “if you’re gonna do code generation, write a dumb program that generates source code text, run it and check the result into source control” was a revelation - yeah, it’s ugly, but guess what? It can be debugged by human beings.

It depends more on whether the language tooling supports it. I used Lombok back in the day with Netbeans. When properly setup it would pop to the generated code when debugging or if you went to a definition, pretty easy.

I was thinking about that just the other day, who it would be really cool if Go had compile time code execution. I think Jai is making that a very prominent feature of the language.

re: Jai. I have never seen a language that is not even available get so much love and benefit of doubt.

I don't know if there's ever been a language that was announced 10 years before its first closed beta. I don't even know if having a "closed beta" for a language is something that really happens.

So there's a lot that is different with Jai, it's more like a highly anticipated game than a language.

cult of personality

Isn't Jai still vapourware after a decade ? How does one even get the compiler and build programs ?

> Isn't Jai still vapourware after a decade ?

Yes, I guess. I wouldn't be surprised to see "Jai inspired" languages coming out before Jai itself, since some of the ideas look pretty good.

> How does one even get the compiler and build programs ?

Don't know how seriously you're asking this, but I believe you can apply to use it and if Jon likes your credentials and what you want to try it on he might let you have the compiler for some version. Don't know why he won't just open source it and say it's a early version passive of change, but game development is not usually very open source friendly compared to web dev.

TIL `go build -toolexec`. That... seems like it'd enable a lot of interesting shenanigans...

I'm somewhat surprised by how little I see online about it.

Adding "-a" is probably going to slow down your compile times by quite a bit. If I were going to use something like this, I'd try to ensure the results only depended on things in the same file. I wonder if there's a way for `prep` to warn when the result depends on something outside the file.

If there were language support for this sort of thing, it could track the dependencies itself.

I'd been looking at https://github.com/cosmos72/gomacro/ on and off to get similar functionality.

(and by "looking at" I mean "kept meaning to try it but totally haven't got round to it yet" but I still think it's worth a look)

If I need to do compile-time pre-computation, I'd probably do it using "code generation" using something like this: https://github.com/linzhp/codegen_example/tree/master

* integrated into bazel rather than go-compiler-hacking * your "normal" code just imports the result - which can be go-to-definition-ed to see the generated code

I wonder what Go would look like if it had generics removed but something like comptime added.

comptime really should have been the approach to Generics taken by Golang instead of trying to blindly follow Java/C++ . It would have also fit into Go's philosophy of keeping it standard and simple - no separate mini language for generics . Wish the language designers had looked at Zig before rolling out generics.

Actually the way they were introduced, they are following up CLU from 1976!

In an older project I have had a code file generated with constants to get same results.

That is nice. Makes coding and build flow simple, clean and easier to maintain.

Other than a traditional compiler use case and stage, "codegen" is an obvious anti-pattern both for security and for a maintainer's complexity burden, and thus to be avoided.

Just say no, kids. Life will be better.

I don’t know if zig is going to become mainstream, but comptime is such a brilliant yet simple idea (the best ones) that it’s already written its name in the hallmark of programming languages.