Too regular? I gotta be honest, that comment makes very little sense to me. My problem diving into most codebases (over 10 years spent contracting) was always multiplied horrifically by non-idiomatic code in language X.
Bob the developer has his own ideas about what + should mean... and uses gobs of hard to puzzle through magic all over the place. You need to run this C++-alike code through Bob's Pre-Processor -- but it is fine, cause if QT can do it, Bob can do it.
I want to read the code to understand the goal and the means for achieving it, not to be impressed with your brevity or cleverness.
Go was/is developed for teams, which means to some degree to the lowest common denominator. So far, in the last couple years, I have -- in general -- come to see these trade-offs as generally wise. Go is exceptional pragmatic for working on a team.
> Too regular? I gotta be honest, that comment makes very little sense to me.
Not agreeing or disagreeing with the parent, but I believe he may be referring to a common problem in software development that is best summed up by a quote by Yaron Minsky: "You can't pay people enough to carefully debug boring boilerplate code. I've tried."
If your Go code is just a series of `if x, err := foo(); err != nil { ... }`, it can become easy during code review to miss subtle bugs because in one function somewhere, someone write `err == nil` instead. This is not unique to Go; many programmers feel the same way about Java.
I find that one of Go's weakness is its limited ability to abstract common patterns. I also believe that for some languages (e.g. Haskell, Common Lisp, Scala) their main weakness is their apparent unlimited ability to abstract common patterns, sometimes beyond the understanding of most programmers. I'm not smart enough to come up with (a) an objective way to measure how little/how much a language allows abstraction, (b) a language that would hit a sweet spot of allowing abstraction without going into the deep end.
The problem is the sweet spot moves, and it can also be different between individuals and teams. I wouldn't even be surprised to learn that the sweet spot for a team is a lower level of abstraction than any individual team member is capable of, partially due to communication reasons and partially because "abstraction comfort" is not really on a line and you probably ought to target the minimum for any given "element" of it on your team.
It's why I've said before that while I'd very much like to work with Go, it's not my personal favorite. I'm comfortable with Haskell, but I would be engaging in malpractice to put code into the source control system that requires that level of fluency with abstraction to understand. Go has a really solid balance for large teams. If you're currently in a startup with 5 well-chosen, high-skill engineers, you won't have any clue what I mean by that, but when you've got hundreds of engineers who may touch some bit of code, where most of them are trying to spend as little of their cognitive budget as possible on it so even the very smart and very skilled ones are pretty much just stabbing the code until it does what they want it to, you start to appreciate a language that limits how hard they can twist the knife.
The opposite of too regular is not necessarily "abuse of the C++ preprocessor" or unwarranted cleverness.
The same phenomenon exists in natural languages: The sentence structure in some passages of the bible is just too regular for me to be interesting, great authors on the other hand have an individual style while still writing with great clarity.
Go is a miser. It gives you very few features to play with, forcing you to think hard about how you can solve real problems with these features in the most economic way. The result is much less fun, and the code you write is dull. But it is still useful, often as useful as what you write with a more fun language. And the probability that you will change your code because "feature X is the new hype" is considerably lower.
Go is not perfect in any sense of the word; every now and then its feature set turns out to be genuinely limited, and you have to apply hacks. But sometimes when you are forced to think hard, it turns out that you can combine two or more dull features in a creative way to do something you thought were only possible with new, interesting features. This offers a perspective of looking at language features: what are really necessary, and what are there just because programmers want to have fun?
Parsimony is a virtue appreciated everywhere in science and technology, except programming, where languages are rated by the number of features they include, and complexities get added to systems until they explode. The go perspective is a very, very valuable one in such a world.
> Parsimony is a virtue appreciated everywhere in science and technology, except programming, where languages are rated by the number of features they include, and complexities get added to systems until they explode.
You're laughably wrong.
There is an important school of thought in programming language design that emphasizes and heralds "language features" that are orthogonal, internally consistent and lean. In this school of thought, it is a plus (sometimes imposed as a necessity) when something can be expressed in the language by simply combining the primitive built-in "language features" in a certain way - as opposed to creating another "feature" altogether. And it is a plus when the list and specification of language features is short. And no - people who belong to this school of thought won't pine for more "features" so that they can make the whole thing more complicated for minor conveniences.
Ask yourself. Which of these two languages are more likely to be complemented by language nerds/snobs - C++, or Scheme...
And some people who apparently belong to this school of thought are criticizing Go for not being orthogonal enough. I wouldn't know about that - you would have to ask them about that. But if history is any indication, when something in Go is pointed out as not being orthogonal or simple, the goal post will change to nebulous claims of "pragmatism".
We are advocating the same school of thought. However languages designed by such schools rarely get mainstream - Scheme, Lua, Smalltalk, to name a few that I know of. People acknowledge them, put them on the altar and ignore them. Go is the first language in decades I know of that boasts simplicity as a feature and gets mainstream; C is the last one before Go. There are things I dislike about Go (esp. lack of generics), but I find it worth defending. I apologize for my somewhat cynical intonation, if that caused confusions.
> Ask yourself. Which of these two languages are more likely to be complemented by language nerds/snobs - C++, or Scheme...
I don't understand this question.
> And some people who apparently belong to this school of thought are criticizing Go for not being orthogonal enough.
I am very eager to hear such criticisms, but I haven't come across any of them. Most "criticisms" on Go are simply "Go lacks feature X", which are simply invalid. A valid criticism is "It is very tricky for me to solve problem X with Go, and adding feature Y will make things easier", but I don't always buy it unless the author is smart enough to convince me that the difficulty lies in the limitation of Go instead of the author's intelligence.
I think some of those "Go lacks feature X" are the arguments you're eager to hear, and not simply invalid. Go lacking generics but having generic map/array types built in is an example of going against the Scheme school of thought. They're not built up from primitive features, but handed down as language features.
In addition to those, there is Iota. Which is completely special-cased syntax sugar, which is not reusable outside of a single context. You can't use it at all more generally, and get potentially non-obvious code from using plain integers silently.
> Ask yourself. Which of these two languages are more likely to be complemented by language nerds/snobs - C++, or Scheme...
I realized that you might have meant "compliment" instead of "complement". The answer depends entirely on what you call a "language nerd". For me, Scheme is a beauty to behold while C++ is an abomination.
But the depressing fact is that C++ is used way more than Scheme, even in areas where Scheme is clearly more suited. This is why I am enthusiastic about go; it can hardly represent the entire "simplicity and orthogonality" school, but it makes very practical use of its simplicity: very regular code, friendly learning curve, intuitive tooling, rich IDE plugins, fast compilation, simple deployment, etc. Eventually some will start to think about the reason for these advantages and appreciate simplicity on practical ground.
Arguably, Go (and C) differs from the other languages of the orthodox "simplicity and orthography" school. Conceptually, go is much more complex than, say, Smalltalk. But most, if not all, constructs in go can be mapped to their machine representations in a simple and efficient way. So rather than adhering strictly to conceptual simplicity, go actually prioritizes "practical simplicity" and apply conceptual simplicity whenever possible. The result is a very well-thought trade-off that I appreciate - the language is simple enough without sacrificing too much performance or making the compiler hard to write - it is much more tricky to write an good compiler for the other conceptually simple languages.
Anyway, I still loath the lack of generics in go. People are always pointing to Russ Cox's generic dilemma (http://research.swtch.com/generic) when topics on generics are brought up. Come on, you have to make trade-offs and there are cases where it is really useful...
I don't have this problem with functional languages or C written in a free flowing coding style like djb's.
Is it even possible in Go to have an individual style?