4 ms·

> don't call Go or any other popular language "poorly designed" with a short blog post. Instead, say "it doesn't fit my current needs." that's not what the aut

> don't call Go or any other popular language "poorly designed" with a short blog post. Instead, say "it doesn't fit my current needs." that's not what the author wanted to say though. very, very often someone says "this is bad" when they actually mean "this doesn't fit me". in this scenario, I think the author made a very good case for "it's poorly designed".

cs702 11y ago
RodericDay: Language design decisions by superstars like Robert Griesemer, Rob Pike, and Ken Thompson (the creators of Go) that may seem inconvenient or annoying when working on small to mid-size projects could very well make life much easier when working on giant projects which take years and do not fit on any single person's head. I'm reminded of this insight by Lawrence Kesteloot of Dreamworks: "What’s particularly hard is having technical discussions with someone who hasn’t broken through as many walls as you have. Breaking through these walls means making different trade-offs, and specifically it means making a decision that seems to make less sense in the short term but will help later. This is a hard argument to make—the short term advantages are immediately demonstrable, but I can’t convince anyone that a year from now someone may make an innocent change that breaks this code."[1] Unless you personally have led Internet-scale mission-critical software projects at a place like Google, as the authors of Go have, I don't think you're in a position to judge their decisions too harshly. Neither am I, BTW. -- [1] http://www.teamten.com/lawrence/writings/norris-numbers.html http://www.teamten.com/lawrence/writings/norris-numbers.html
- spion 11y ago
  I keep seeing this argument all the time. Lets put a counter-argument-by-authority: Fran Allen [1] thinks that the C was a huge step backwards in language design [2], and there is no reason to think that Go didn't repeat the same pattern. Interestingly, the article you quoted mentions functional programming and immutable data as the step to go from 200K to 2M lines. Go is fundamentally incapable of functional programming* and its builtins allow pervasive mutable state. [1]: https://en.wikipedia.org/wiki/Frances_E._Allen https://en.wikipedia.org/wiki/Frances_E._Allen [2]: http://www.amazon.com/Coders-Work-Reflections-Craft-Programming/dp/1430219483 http://www.amazon.com/Coders-Work-Reflections-Craft-Programm... * Its impossible to support FP without generics. Even the most basic higher order functions require type variables.
  - ngrilly 11y ago
    The guarantees offered by functional programming and immutable data are great, but they mostly evaporate when you move from a single process application to a multiple processes system, distributed on many machines and communicating through IPC. Are you aware of a 2M lines code base that fully relies on FP and immutable data?
    - kibwen 11y ago
      Erlang's very existence is a pretty solid refutation of the claims you're putting forth. :P
      - ngrilly 11y ago
        I don't think so. An Erlang process has no mutable state. But it can communicate with another Erlang process to set/get some state. This is how a lot of mutable structures are implemented in Erlang.
    - deepnet 11y ago
      I beg to differ: the guarantees functional programming and data immutability offer are exactly the sorts of guarantees needed for scalable parallelisation. LOC is not a useful metric for the utility of a program, in fact the reverse is true in terms of maintainability and places for bugs to hide. This chap claims to write very robust programs, entirely functionally that are worth billions in their operation. http://logicaltypes.blogspot.co.uk/2015/08/pure-functional-programming-claims-irl.html http://logicaltypes.blogspot.co.uk/2015/08/pure-functional-p...
      - ngrilly 11y ago
        I agree that "the guarantees functional programming and data immutability offer" are very useful for "scalable parallelisation". But this is not what I was answering to. I was answering to the idea that FP and immutability are useful when you scale from 200K to 2M lines of code: > the article you quoted mentions functional programming and immutable data as the step to go from 200K to 2M lines In my opinion, this argument is irrelevant.

cs702 11y ago

RodericDay: Language design decisions by superstars like Robert Griesemer, Rob Pike, and Ken Thompson (the creators of Go) that may seem inconvenient or annoying when working on small to mid-size projects could very well make life much easier when working on giant projects which take years and do not fit on any single person's head. I'm reminded of this insight by Lawrence Kesteloot of Dreamworks: "What’s particularly hard is having technical discussions with someone who hasn’t broken through as many walls as you have. Breaking through these walls means making different trade-offs, and specifically it means making a decision that seems to make less sense in the short term but will help later. This is a hard argument to make—the short term advantages are immediately demonstrable, but I can’t convince anyone that a year from now someone may make an innocent change that breaks this code."[1] Unless you personally have led Internet-scale mission-critical software projects at a place like Google, as the authors of Go have, I don't think you're in a position to judge their decisions too harshly. Neither am I, BTW. -- [1] http://www.teamten.com/lawrence/writings/norris-numbers.html http://www.teamten.com/lawrence/writings/norris-numbers.html

spion 11y ago
I keep seeing this argument all the time. Lets put a counter-argument-by-authority: Fran Allen [1] thinks that the C was a huge step backwards in language design [2], and there is no reason to think that Go didn't repeat the same pattern. Interestingly, the article you quoted mentions functional programming and immutable data as the step to go from 200K to 2M lines. Go is fundamentally incapable of functional programming* and its builtins allow pervasive mutable state. [1]: https://en.wikipedia.org/wiki/Frances_E._Allen https://en.wikipedia.org/wiki/Frances_E._Allen [2]: http://www.amazon.com/Coders-Work-Reflections-Craft-Programming/dp/1430219483 http://www.amazon.com/Coders-Work-Reflections-Craft-Programm... * Its impossible to support FP without generics. Even the most basic higher order functions require type variables.
- ngrilly 11y ago
  The guarantees offered by functional programming and immutable data are great, but they mostly evaporate when you move from a single process application to a multiple processes system, distributed on many machines and communicating through IPC. Are you aware of a 2M lines code base that fully relies on FP and immutable data?
  - kibwen 11y ago
    Erlang's very existence is a pretty solid refutation of the claims you're putting forth. :P
    - ngrilly 11y ago
      I don't think so. An Erlang process has no mutable state. But it can communicate with another Erlang process to set/get some state. This is how a lot of mutable structures are implemented in Erlang.
  - deepnet 11y ago
    I beg to differ: the guarantees functional programming and data immutability offer are exactly the sorts of guarantees needed for scalable parallelisation. LOC is not a useful metric for the utility of a program, in fact the reverse is true in terms of maintainability and places for bugs to hide. This chap claims to write very robust programs, entirely functionally that are worth billions in their operation. http://logicaltypes.blogspot.co.uk/2015/08/pure-functional-programming-claims-irl.html http://logicaltypes.blogspot.co.uk/2015/08/pure-functional-p...
    - ngrilly 11y ago
      I agree that "the guarantees functional programming and data immutability offer" are very useful for "scalable parallelisation". But this is not what I was answering to. I was answering to the idea that FP and immutability are useful when you scale from 200K to 2M lines of code: > the article you quoted mentions functional programming and immutable data as the step to go from 200K to 2M lines In my opinion, this argument is irrelevant.