Go is still not good

Go has its fair share of flaws but I still think it hits a sweet spot that no other server side language provides.

It’s faster than Node or Python, with a better type system than either. It’s got a much easier learning curve than Rust. It has a good stdlib and tooling. Simple syntax with usually only one way to do things. Error handling has its problems but I still prefer it over Node, where a catch clause might receive just about anything as an “error”.

Am I missing a language that does this too or more? I’m not a Go fanatic at all, mostly written Node for backends in my career, but I’ve been exploring Go lately.

Yeah the big problem is that most languages have their fair share of rough edges. Go is performant and portable* with a good runtime and a good ecosystem. But it also has nil pointers, zero values, no destructors, and no macros. (And before anyone says macros are bad, codegen is worse, and Go has to use a lot of codegen to get around the lack of macros).

There are languages with fewer warts, but they're usually more complicated (e.g. Rust), because most of Go's problems are caused by its creators' fixation with simplicity at all costs.

I thought it was obvious that codegen was better than macros—at least, textual macros. You can't tell me Ken Thompson omitted macros from the Golang design because he didn't have experience using languages with macro systems!

Even AST-based macro systems have tricky problems like nontermination and variable capture. It can be tough to debug why your compiler is stuck in an infinite macro expansion loop. Macro systems that solve these problems, like the R⁵RS syntax-rules system, have other drawbacks like very complex implementations and limited expressive power.

And often there's no easy way to look at the code after it's been through the macro processor, which makes bugs in the generated code introduced by buggy macros hard to track down.

By contrast, if your code generator hangs in an infinite loop, you can debug it the same way you normally debug your programs; it doesn't suffer from tricky bugs due to variable capture; and it's easy to look at its output.

I would say more or less equivalent to textual macros. Unfortunately, as far as I can tell, the idiomatic way to write Go codegen (having skimmed some codegen repos and written some codegen tooling myself) is with the text/template package. Even battle-tested tools like protoc-gen-go are effectively built with printf statements rather than any sort of AST builder.

AST macros are complicated, yeah, and I agree that any half-decent macro system needs a convenient way to dump generated code and so forth. I'm not saying any macro system is better than codegen. But a decent macro system will give you hygenic tools to modify an AST, whereas codegen really forces you to hack something together. I'll grant that there's some worse-is-better charm to codegen, but I don't think that saves it from being ultimately worse.

A code generator is just a compiler; general arguments against code generation work equally well as arguments against using a compiler.

Writing a compiler is not "worse is better" and does not force you to hack something [fragile] together. Therefore, your argument is wrong.

Empirically, I think you'll find that Go code generators are bad compilers. Go codegen isn't written with AST transformations and quasi-quote libraries. A macro system would be an opportunity for the Go compiler to take responsibility for the the tooling around metaprogramming; in the absence of that, we have a fragmented ecosystem where everyone is always reinventing a minimal, hacked-together version of the wheel so that they can get on with building the thing they actually need.

Frankly, an official Go codegen library would solve pretty much all my complaints, but the only difference between that and a macro system is compiler integration.