11 ms·

My summary of the author's points: no generics, inexpressive, no good package manager, procedural. Of these, caring about the fact that it is procedural seems

• sethetter 12y ago
  "Expressiveness" seems like a subjective measurement to me. Also, from what I've gathered, Go attempts to be more convention oriented and is centered around doing things the "one true way". The Go formatter is an example of this. Perhaps this is just a result of that philosophy.
• AlexandrB 12y 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.
  • carbocation 12y 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 12y 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.
      • NateDad 12y 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 12y ago
          From the Go FAQ (https://golang.org/doc/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.
          • NateDad 12y ago
            The type system is a concern about the complexity for the users of Go, not for the compiler developers.
  • jmtulloss 12y 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.
    • AlexandrB 12y ago
      Take a look at this: http://programmers.stackexchange.com/questions/185660/is-the-average-number-of-bugs-per-loc-the-same-for-different-programming-languag http://programmers.stackexchange.com/questions/185660/is-the... Bug counts/kloc seem to be consistent across languages.
      • AlexandrB 12y ago
        To add to this, implementing a bunch of boilerplate often means copy/pasting code. That means you risk introducing mistakes where one copy is wrong[1]. [1] http://www.viva64.com/en/b/0260/ http://www.viva64.com/en/b/0260/
        • NateDad 12y ago
          You assume that Go's simplicity means you end up copying and pasting a lot of code. This is just not the case. In juju (https://github.com/juju/juju https://github.com/juju/juju), a ~300kloc project, we have approximately one single type that we've copy & pasted where a generic implementation would have been better (it's a set). And honestly, implementing full set functionality was not even really necessary, someone just felt like doing it.
  • slantedview 12y 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 12y 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.
• pivo 12y ago
  I hadn't really looked at Go before, but I have to say the generics issue reminds me of Java 10 years ago before it got generics. Java also had the goal of being simple, which is probably why it's so popular, but for me it was always too simple in the sense used in TFA (haven't tried Java8 yet though.) At least it looks like Go has higher order functions, but I don't see how they will be that useful without generics unless you subvert the type system. I definitely think the too-simple nature of Java is the reason behind all the reams of boilerplate Java code found in most any Java project, and I can't see how Go would be any different. It seems like a shame not to have learned that lesson.
  • davecheney 12y ago
    If you want a more complex Java you can have Scala. Scala remains hostile to newcomers with an almost vertical learning curve. I don't think anyone can seriously argue that commercial programmers need a more complex language.
    • frowaway001 12y ago
      "Why should I ever wash my hands before a medical procedure? It just makes things more complex!" –– Surgeon, ~1700.
      • davecheney 12y ago
        What a feckless comparison. Don't mistake something taking more time with something being more complex.
      • Gigablah 12y ago
        Comparing Scala's complexity to a life-saving procedure says more about your own self-importance than anything.
        • krenoten 12y ago
          Strong type systems absolutely save lives.
• mmcclure 12y ago
  > PHP's package manager, for example, is not coupled to the core language "Lacking a package manager isn't a language issue, this language that's nearly universally derided doesn't have one." I see what you're saying, but that strikes me as a really bad example. That being said, it is strange to me that a modern language wouldn't have any reasonable story around package management. The argument I've most commonly heard is that applications should be very small bits of functionality, thus making a full-blown package manager unnecessary...sure, that seems reasonable...except dependency management is still (aside from the whole generics flame war) one of the most common complaints I've heard from Go devs. To be honest, I don't understand all the vitriol. That's by far the most bizarre thing about Go to me.
  • shebson 12y ago
    A more appropriate example might be Python. It didn't ship with Pip by default until Python 3.4 (released in 2014).
  • benihana 12y ago
    It's bizarre to me that you started your post by dismissing an entire language based on popular opinion then end it by saying you don't understand the vitriol people have about a different language.
    • mmcclure 12y ago
      I personally don't understand the vitriolic posts on Go. I personally do understand the vitriolic comments about PHP, of which there are examples that are well-reasoned and go beyond "no generics!"[1] [1] http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design
      • Gigablah 12y ago
        It's 2015, the PHP ecosystem has progressed. Citing that blog post hurts your argument more than it helps.
• ralfn 12y ago
  >So, we are left with the lack of generics and the lack of expressivity. I'm not deep enough in the weeds to be able to argue pro/con for generics intelligently right now, so I will concede that as a concern that has been raised by many. "Generics" is not a feature, its a bugfix. It refers to the type checker not rejecting perfectly fine code. In practice, you can just read 'generics' as 'this product does not contain asbestos', or "the mandatory type checker does not reject perfectly fine code". Type systems are supposed to help you catch bugs at an earlier stage than run-time execution. However, implementing a type system is very hard and academic in nature, and the type of people who are good at making production ready high performance compilers generally aren't very good at type checkers. This is why many languages initially launch with a broken type system (and often a broken garbage collector), but eventually patch things up. The problem Go has, is that its main author makes such cringe-worthy statements about generics, that we now have a large group of enthusiastic people who, on the basis of authority of the author, exclaim equally confusing remarks. Everything got so defensive that this typical launch bug, normally fixed with a release or two, is now part of the culture and DNA of this particular ecosystem. The sad thing is, these are all talented people, that instead of impressing us with their awesome skills, are embarrassing themselves in front of anybody who ever read anything about category theory. For example, here's a "generic" algorithm to fold the (+) operator in Javascript: function( xs ){ var result = 0; for( var i=0; i<xs.length; i++ ) result = result + xs[i]; return result } No type checker, no fuzz. There is nothing complicated here. But if you translate this to Go, you would you would need to copy this code over and over again for every potential leaf type you want to use this algorithm with and change only the type signature. The complexity is actually the result of a mandatory type checker that is broken by design. The most simple solution to support 'generics' would be to make the type signature optional.