← Back to context

Comment by meowface

11 years ago

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.

5 comments

meowface

Reply
MetaCosm  11 years ago

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...

NateDad  11 years ago

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.

  • meowface  11 years ago

    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.