“Go’s design is a disservice to intelligent programmers”

I believe that the purpose of `go generate` is to lessen the risk of this type of thing by handling the repetitive code generation for you, but I do agree that it's a limitation. If done by `go generate`, it's an additional procedure that you have to learn; if done by hand, it's a bug risk.

Code generation is a giant spiked mallet for a nail which can easily be screwed with a small screwdriver. It has its uses, especially for generating schemas (like what Protobuf and Capnproto do), but for generating actual function implementations it's kind of absurd. `go generate` is a nice tool but it's not even remotely a solution to the no-generics problem.

Of course, the problem is that for the compiler implementation, those traits are completely reversed (adding generics at this point is like hitting the compiler with a mallet); and that happens to be Go's primary excuse for lack of generics/templating/macros/anything sane. I think dev ease-of-use matters a lot more than core dev ease-of-use though. Even if the compiler must grow in complexity and average compile time, the benefits to devs are worth it.

No one has ever said that the compiler implementation would be too hard, and that's why there's no generics in go. People need to stop saying that, because it's bullshit.

From the Go FAQ (https://golang.org/doc/faq):

>Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.

Not hard as in "can't do it", but hard as in too hard to implement without adding the ever feared "complexity".

For the record, I like Go and its philosophy, but I think, above all other issues with the language, the lack of generics is a huge weakness and will eventually be looked back on as a mistake. Not just for not having them before 1.0, but also for waiting as long as they did for adding them, assuming they ever do add them.

The type system is a concern about the complexity for the users of Go, not for the compiler developers.

How exactly? Ignoring issues of backwards compatibility for the moment, I don't think Java's introduction of generics added a ton of complexity for developers, and I don't see why Go would either. In Java's case it seemed like the complexity was definitely on the compiler side, due to their type erasure approach.

I admit I'm not an expert in programming language design though, so I may be completely wrong about both Java and Go.

As someone who has repeatedly done code generation on the C++ side to avoid build-hell (text files with expansion into C++ files) -- I can't agree with this. Your trivialization of complex C++ build times is nonsensical and reeks of inexperience -- it ruins everyday -- it ruins cycle time -- it sucks joy and creativity out of development... long build times are atrocious which is why insane effort is being spent to try to lower them in C++.

Lots of C++ "features" on banned on major projects because of complexity and build time issues -- templates, exceptions, operator overloading...