A fantastic idea, even slower to compile (since you need to parse extra source files), more complex workflow, and extra files which developers have to remember to ignore.

This is exactly the case that the problems of a language are solved by tooling. This attitude can be easily found in the Java ecosystem, where the answer to every question is "to use IDE". Interestingly, Java recently abandoned the idea of feature stagnation and started improving the language. I'm curious when this will happen to Go.

Slower to compile, but starting from a much faster starting point.

I'm not even aware of go compiling most of the time (it's typically under 1 second). go's build system handles these sort of things without a more complex workflow.

> I'm not even aware of go compiling most of the time (it's typically under 1 second).

That's besides the point, codegen from extra on-disk files can only be slower than codegen without extra on-disk files, so "generics are slow to compile" and "go has generate" don't make sense together, yet they are used together to assert that generics are bad and anyway go has a replacement.

> go's build system handles these sort of things without a more complex workflow.

No they don't. If you're using go generate you have to run go generate. That's a strictly more complex workflow than not having to run it.

I didn't say generics were bad. I said compilation is so fast that I didn't notice it.

While I agree that "strictly" your assessment is corect it's more complex, I think you're being a bit literal; it's just another command. most of my builds have hundreds of commands.