← Back to context

Comment by AlexandrB

11 years ago

I thought the "sum" example was pretty damning. Bug count scales with code length so writing tons of boilerplate code to work around language limitations means you're introducing bugs.

13 comments

AlexandrB

Reply
slantedview  11 years ago

This, and boilerplate != simplicity. The D example in the article - now that is simplicity. Language designers would be well served to acknowledge this.

falcolas  11 years ago

As a programmer who is writing Go for a living: the lack of generics is not actually that big of a problem in your day to day work.

Yes, if you want to generalize code to release a library to a much wider audience, you'll either end up writing quite a bit of duplicate code, using the code generation tools, or diving into the "reflect" package (which would let you write Sum in one method).

That said, I've never had to do either of these in writing about 10k lines of Go code.

carbocation  11 years ago

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.

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

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

      3 replies →

jmtulloss  11 years ago

In my opinion, bug count scales within a code base with code length, but you can't really compare languages and say that the shorter one must contain fewer bugs. A more expressive language means you can cram more bugs in fewer lines.