5 ms·

They refer to the complexity of the compiler and language, not to user code complexity. Any given language has a complexity budget and they wish to expend it el

• nf 12y ago
  No, that is not what I was referring to. It is definitely user code complexity that turns us away from generics. People tie themselves in knots with generics all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase.
  • spion 12y ago
    I'd say people tie themselves in inheritance and interface knots more often than generics knots. Especially invariant generics are rather hard to get wrong - they place such constraints on the types that most operations are unavailable.
  • mercurial 12y ago
    As somebody using pre-generics Java libraries from time to time, I can say with confidence that generics are not the cause of complexity. Casting from Object is a source of bad type safety and doesn't help with documentation. The complexity you'll find in a mature codebase is a function of the way it is architectured and the complexity inherent to the domain, mostly.
    • NateDad 12y ago
      I wish people wouldn't assume there's only two options - Generics or casting from Object/interface{}/void* It's a straw man argument. No experienced Go programmers are trying to say that's a good way to write code. The idea is to restructure your code so that basic data structures and interfaces pick up the majority of your reuse scenarios.
      • mercurial 12y ago
        I'm no Go programmers, but I relatively often need to take a parametrized basic data structure as storage and write a parametrize class on top of it, while hiding the data structure because it's irrelevant. Well, I guess I'll keep not being a Go programmer :)
  • the_af 12y ago
    > People tie themselves in knots with generics all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase. That's not my experience at all. Generics are generally not a source of pain. Do you have any specific examples of your claim?
  • tomp 12y ago
    People tie themselves in knots with classes/packages/interfaces/concurrency/computer code all the time. Just look at pretty much any mature codebase at all.
• sriku 12y ago
  That's a weird stance. If there are complexities that programmers face that can be absorbed by a compiler, it must be, because that would pay off for every programmer , in every project, in every bug prevented.
  • latch 12y ago
    In the Go FAQ [1], when they list the purpose of the project, the first answer they give isn't about concurrency (as some might suspect), it's: "It is possible to compile a large Go program in a few seconds on a single computer." They've been consistent about this. It's a major design goal and, for some, compilation speed is worth more than support for Generics. [1] http://golang.org/doc/faq#What_is_the_purpose_of_the_project http://golang.org/doc/faq#What_is_the_purpose_of_the_project
    • gnuvince 12y ago
      And yet, the dmd compiler for D support templates and is faster than the gc Go compiler.
      • enneff 12y ago
        I'll say it again: Go doesn't have generics because of implementation complexity. The tradeoff was against the additional complexity that our users would have to deal with.
        • gnuvince 12y ago
          I was only addressing the comment of the parent that suggested adding parametric polymorphism would kill compiler performance.
        • mlatu 12y ago
          right, because a big codebase to deal with the lack of generics doesnt add complexity at all. you see, the problem with the complexity of a language isnt real. it is perfectly possible to avoid generics in c++ forever. but there will come a day when you think to yourself, was it really worth it to be this lazy? then you take a peek and (assuming you understand generics by then enough to use it a little) suddenly half of what you have writen so far is for the bin.