7 ms·

I think it's rather the height of hubris to accuse your contemporaries of being "ignorant" because they disagree with your assessment of this particular tool.

I think it's rather the height of hubris to accuse your contemporaries of being "ignorant" because they disagree with your assessment of this particular tool. Go is an interesting shift in language design, basically discarding many modern trends and techniques and returning to a much simpler paradigm. It's a totally valid approach with lots of merit — complexity can be a killer. In addition, the concurrency primitives, decent stdlib and tooling make Go pretty great to use in some respects. It's likely to be well-supported for a long time and is a suitable tool for many tasks. On the flipside, using it often feels like a bit of a slog. Error handling is simple (good) but repetitive (bad). Keeping generics out of the language avoids complexity (good) but results in repetitive and awkward code (bad). Lack of features like pattern matching and higher-order functions makes some code irritatingly tedious to read and write. And so on. Point is, it's perfectly valid to look at these decisions and say "I don't like Go because it is missing these features", as much as it's valid to say "The simplicity of Go is a useful feature". Ignorance is not a prerequisite for disagreement. So please have some respect for opinions which differ from your own, and think about offering something a little more constructive than insults.

xkarga00 12y ago
Just a note: Go supports higher-order functions
sesteel 12y ago
I agree, I should have grounded the claim of ignorance in a long list of specific instances or made no comment at all; sometimes less is more. Aside, I use and enjoy languages other than Go; it is simply a tool to solve problems, and I don't want to detract people from using other tools. We all develop opinions with regards to what does and does not work well. I never intended to devalue others' experience or perspective. I was simply pointing out that many people seem to not have suffered through enough bad work experiences to appreciate Go's main feature of simplicity. If you haven't run across horrible, insanely overcomplicated, code written by those that think they are the top 1% intelligence-wise, you might not appreciate Go. Likewise, if you write horrible, insanely overcomplicated, code and think you, yourself, are brilliant, you probably won't appreciate Go. If you only work alone or on small teams and projects, you might not appreciate Go.
yomism 12y ago
Minor corrrection: Go supports higher-order functions (They even have a codewalk that mentions this in its introduction) https://golang.org/doc/codewalk/functions/ https://golang.org/doc/codewalk/functions/
mavelikara 12y ago
In an essay titled "Why Pascal is Not My Favorite Programming Language"[1] Brian W. Kernighan wrote: The size of an array is part of its type If one declares var arr10 : array [1..10] of integer; arr20 : array [1..20] of integer; then arr10 and arr20 are arrays of 10 and 20 integers respectively. Suppose we want to write a procedure 'sort' to sort an integer array. Because arr10 and arr20 have different types, it is not possible to write a single procedure that will sort them both. The place where this affects Software Tools particularly, and I think programs in general, is that it makes it difficult indeed to create a library of routines for doing common, general-purpose operations like sorting. People who complain about the lack of generics in Go are making the same argument that Kernighan made against Pascal viz. that it is tedious to write library code in the language. EDIT: Also it is not uncommon for a feature that is deemed essential by some to be thought of as adding too much complexity by others. For example, "I've seen [visual] editors like that, but I don't feel a need for them. I don't want to see the state of the file when I'm editing." said Ken Thompson [2] when comparing line editors like ed to visual editors like vi or emacs. [1]: http://www.lysator.liu.se/c/bwk-on-pascal.html http://www.lysator.liu.se/c/bwk-on-pascal.html [2]: http://web.archive.org/web/20080103071208/http://www.dcs.qmul.ac.uk/~george/history/ http://web.archive.org/web/20080103071208/http://www.dcs.qmu...
- gnuvince 12y ago
  In a funny twist of history, Kernighan is now writing a book on a language where the length of an array is part of its type: http://play.golang.org/p/jrbSgKFZ_1 http://play.golang.org/p/jrbSgKFZ_1
  - nemo1618 12y ago
    Technically true, but the point is that arrays were the only collection type in Pascal, whereas Go also has slices (which, in my experience, outnumber arrays 10-1 in most codebases).
    - gnuvince 12y ago
      When did Pascal gain dynamic arrays?
stcredzero 12y ago
complexity can be a killer Complexity is also the mind killer. However, it kills with ten thousand cuts, not with one fell stroke. This is why the prideful are even more vulnerable!
daviddaviddavid 12y ago
"Ignorance is not a prerequisite for disagreement." This is a very memorable and useful quote. Thanks for saying it. It deserves to be a classic, in my opinion.
- Retra 12y ago
  Except that it is not always true. Ignorance is a prerequisite for disagreement if you assume entirely rational decision-making. Without ignorance, if you have disagreement, you very likely have irrationality instead.
  - recursive 12y ago
    Is rationality incompatible with subjectivity?
    - Retra 12y ago
      Of course it is. This is probably expressed most clearly in Bayes' Theorem. (http://en.wikipedia.org/wiki/Bayes%27_theorem http://en.wikipedia.org/wiki/Bayes%27_theorem)
  - dragonwriter 12y ago
    > Ignorance is a prerequisite for disagreement if you assume entirely rational decision-making. This is only true with identical utility functions for all participants. Rational decision making means each actor acts with perfect information about expected utilities of all options and chooses the option that maximizes their own realized utility. Rational actors can easily disagree without ignorance, since rational actors can have different utility functions.
    - Retra 12y ago
      Only if they are ignorant of each others' utility functions.
      - 12y ago
sytelus 12y ago
Go seems to have designed to make compiler beautiful and simple. There was even a brag post about how one of the authors saved few bytes by making a change in the language. My view is that language should be designed to take away repetitive tasks from developer rather than make language pretty or compiler super efficient. It's OK to make compiler complex to meet the demand of important feature that developers would enjoy and want every day.
- enneff 12y ago
  Citation needed. This is flat out wrong.

xkarga00 12y ago

Just a note: Go supports higher-order functions

sesteel 12y ago

I agree, I should have grounded the claim of ignorance in a long list of specific instances or made no comment at all; sometimes less is more. Aside, I use and enjoy languages other than Go; it is simply a tool to solve problems, and I don't want to detract people from using other tools. We all develop opinions with regards to what does and does not work well. I never intended to devalue others' experience or perspective. I was simply pointing out that many people seem to not have suffered through enough bad work experiences to appreciate Go's main feature of simplicity. If you haven't run across horrible, insanely overcomplicated, code written by those that think they are the top 1% intelligence-wise, you might not appreciate Go. Likewise, if you write horrible, insanely overcomplicated, code and think you, yourself, are brilliant, you probably won't appreciate Go. If you only work alone or on small teams and projects, you might not appreciate Go.

yomism 12y ago

Minor corrrection: Go supports higher-order functions (They even have a codewalk that mentions this in its introduction) https://golang.org/doc/codewalk/functions/ https://golang.org/doc/codewalk/functions/

mavelikara 12y ago

In an essay titled "Why Pascal is Not My Favorite Programming Language"[1] Brian W. Kernighan wrote: The size of an array is part of its type If one declares var arr10 : array [1..10] of integer; arr20 : array [1..20] of integer; then arr10 and arr20 are arrays of 10 and 20 integers respectively. Suppose we want to write a procedure 'sort' to sort an integer array. Because arr10 and arr20 have different types, it is not possible to write a single procedure that will sort them both. The place where this affects Software Tools particularly, and I think programs in general, is that it makes it difficult indeed to create a library of routines for doing common, general-purpose operations like sorting. People who complain about the lack of generics in Go are making the same argument that Kernighan made against Pascal viz. that it is tedious to write library code in the language. EDIT: Also it is not uncommon for a feature that is deemed essential by some to be thought of as adding too much complexity by others. For example, "I've seen [visual] editors like that, but I don't feel a need for them. I don't want to see the state of the file when I'm editing." said Ken Thompson [2] when comparing line editors like ed to visual editors like vi or emacs. [1]: http://www.lysator.liu.se/c/bwk-on-pascal.html http://www.lysator.liu.se/c/bwk-on-pascal.html [2]: http://web.archive.org/web/20080103071208/http://www.dcs.qmul.ac.uk/~george/history/ http://web.archive.org/web/20080103071208/http://www.dcs.qmu...

gnuvince 12y ago
In a funny twist of history, Kernighan is now writing a book on a language where the length of an array is part of its type: http://play.golang.org/p/jrbSgKFZ_1 http://play.golang.org/p/jrbSgKFZ_1
- nemo1618 12y ago
  Technically true, but the point is that arrays were the only collection type in Pascal, whereas Go also has slices (which, in my experience, outnumber arrays 10-1 in most codebases).
  - gnuvince 12y ago
    When did Pascal gain dynamic arrays?

stcredzero 12y ago

complexity can be a killer Complexity is also the mind killer. However, it kills with ten thousand cuts, not with one fell stroke. This is why the prideful are even more vulnerable!

daviddaviddavid 12y ago

"Ignorance is not a prerequisite for disagreement." This is a very memorable and useful quote. Thanks for saying it. It deserves to be a classic, in my opinion.

Retra 12y ago
Except that it is not always true. Ignorance is a prerequisite for disagreement if you assume entirely rational decision-making. Without ignorance, if you have disagreement, you very likely have irrationality instead.
- recursive 12y ago
  Is rationality incompatible with subjectivity?
  - Retra 12y ago
    Of course it is. This is probably expressed most clearly in Bayes' Theorem. (http://en.wikipedia.org/wiki/Bayes%27_theorem http://en.wikipedia.org/wiki/Bayes%27_theorem)
- dragonwriter 12y ago
  > Ignorance is a prerequisite for disagreement if you assume entirely rational decision-making. This is only true with identical utility functions for all participants. Rational decision making means each actor acts with perfect information about expected utilities of all options and chooses the option that maximizes their own realized utility. Rational actors can easily disagree without ignorance, since rational actors can have different utility functions.
  - Retra 12y ago
    Only if they are ignorant of each others' utility functions.
    - 12y ago

sytelus 12y ago

Go seems to have designed to make compiler beautiful and simple. There was even a brag post about how one of the authors saved few bytes by making a change in the language. My view is that language should be designed to take away repetitive tasks from developer rather than make language pretty or compiler super efficient. It's OK to make compiler complex to meet the demand of important feature that developers would enjoy and want every day.

enneff 12y ago
Citation needed. This is flat out wrong.