As Go team found out, it's not like people go from C++, OcamL or other full featured languages to Go.
For Python/Ruby etc programmings coming to Go, the lack of features feels exciting, because it makes them think they're programming closer to the metal (what with types, and static compilation, and contiguous arrays, and pointers).
People think Go is worse than other languages because they look at it from a PL theory point of view, ignoring the practical aspects. "Compilation speed? Trivial cross-compilation and deployment? Consistent coding style accross projects? Ability to recruit junior developers/maintainers? Warnings-as-errors? Who needs that?"
>Maybe you're taking the blub paradox backwards. People think Go is worse than other languages because they look at it from a PL theory point of view
That's not the canonical version of the blub paradox though.
In the canonical description it's the increased expression (due to advanced PL features like macros and closures) of the language that can't be appreciated by the blub programer. So, Go is the one that lacks those things.
One could make a case that the other things you mention (compilation speed, cross compilation ease, etc) are also important and should be appreciated, but that wouldn't be the blub paradox.
Besides, other languages can have those as well while keeping their advanced features (compilation speed aside, the rest are more about tooling work, which is orthogonal to the language. And D, for one, can compile as fast as Go, while still having Generics).
In my case, cross-compiling into one binary means it could be the easiest way to build and deploy on an embedded platform where I normally use a quite complex to set up C++ toolchain.
At the same time Go's a typical "sidekick" language, because it's really good only at a few things, unlike C++ or Java which are useable for almost everything.
I've written stuff in C++ as well as Python. The simplicity of Go appeals to me because it means the code is generally more readable (eg people aren't abusing advanced features quite so much).
Anecdotally I've found reading other peoples Go code far easy than I've found reading other peoples code in pretty much any other language. YMMV though
>Anecdotally I've found reading other peoples Go code far easy than I've found reading other peoples code in pretty much any other language
At the micro level yes. At the macro level though, it's easier to understand 10 lines of dense code than the 200 lines Go forces you to write for the same thing. At least you can see them in your screen all at once (and usually express the intent more directly).
For you, perhaps. However for me I completely disagree.
What you're failing to understand is that this is an entirely subjective rather than objective matter. What works for you isn't proof that it's the same for everyone else.
This is why I've said "The simplicity of Go appeals to me", "Anecdotally I've found" and "YMMV" to made it clear in my post that the subject you're discussing is actually a matter of personal taste.
The very fact that we disagree on what we find readable should be evidence enough that it's subjective.
> It's just that as an industry we don't have large scale research into such things.
I don't need large scale research to tell me what I, personally, find easier or harder to read.
Research would tell us what the general rule of thumb is but that's very different to saying there's a definitive rule that applies to everyone uniformly.
> No, but our brains co-developed evolutionary for millions of years for some of us to be widely different than others in how they work.
Forgive me if I'm missing your point here but some people like fast cars and some people like to cycle. Some people want kids while others do not. Some people enjoy working in IT while others want to be gardeners, carpenters, mechanics, doctors, lawyers, etc.
Even specifically to HN, we have enough arguments on here about emacs vs vi; CLI vs GUI; and tiled window managers vs dynamic / overlapping windows to demonstrate that personal preference is alive and well in the field of IT. Yet it's strange how you consider it not to be applicable when it comes to language preferences. I suggest that's failing of imagination on your part.
>I don't need large scale research to tell me what I, personally, find easier or harder to read.
I think we do.
Your phrasing implies that everybody (or at least just you) already and always knows and uses the optimal code styles that make it "easier" for them to read code.
I very much doubt that's the case.
People are deluded about what's "best for them" all the time.
Not to mention "what's best" might change with familiarity with other styles, training, etc, and people could be stuck in a shallow local optimum.
>Forgive me if I'm missing your point here but some people like fast cars and some people like to cycle. Some people want kids while others do not. Some people enjoy working in IT while others want to be gardeners, carpenters, mechanics, doctors, lawyers, etc.
Those are matters of taste. Not matters of cognitive skills and how people read best, learn best, etc.
In fact, the popular myth of personal "learning styles" (X training style being best for some people, Y style best for others, etc) has been demolished.
And yet tons of people confused their "preferences" with some objective reality of their preferred style being better for them.
> Your phrasing implies that everybody (or at least just you) already and always knows and uses the optimal code styles that make it "easier" for them to read code.
No it doesn't. All I've been saying is I find Go - in general - more readable than other languages. Everything else thereafter is you badgering your language snobbishness onto others and me having to say, repeatedly, "I like what I like"
> Those are matters of taste. Not matters of cognitive skills and how people read best, learn best, etc.
"Read best" != "learn best". Anyone who has dyslexia will tell you that they struggle with layouts that others wouldn't take issue with. People who aren't native English speakers also often have different preferences for writing styles to native English speakers.
That can happen. However, when you do not have the proper language features (e.g. pipe operator) then code can become much less readable because it is more verbose and the control flow is unclear.
I think that simple languages only lead to more readable code when the problem domain is also simple.
Not really no. The relationship between verbosity and readability of control flow isn't as clear cut as you describe. For example Java is often praised in threads regarding Go yet that is far more verbose. C++ has all the features you described yet is still more verbose (overall) and less readable than Go.
Plus your post reads as if complex problems doesn't also decrease the readability in more descriptive languages but my experience is complex logic will be inherently harder to read regardless of the language.
I suspect what is actually happening here is your familiarity with language X means you find it easier to read code in language X - and that has nothing to do with verbosity, "proper" language features or whatever else. Personally, however, after 30 years of development on well over a dozen different languages (even some I'd be embarrassed to admit to), Go has consistently been up there for me as one of the easiest to read.
I don't see exactly how my comment connects with yours, so I will just try to clarify / expand on it.
* Java is often hard to read because it is verbose and lacks language features. For example, without operator overloading vector math does not read well.
* C++ (14 upwards) can be made very readable or it can be made very unreadable because it has so many features. I don't think it is obvious that C++ is less readable than Go. Are we talking about the worst case? the best case? the average case?
* The connection between control-flow clarity and verbosity is IMO due to features like the pipe operator and do-notation. These allow you to have code that reads linearly even when the execution is not. The alternative is something with many explicit function calls and nesting that jumps all over the place. Take a look at a Node.js program that uses async/await vs without and you will see what I mean.
* A complex problem domain will lead to harder to read code than a simple domain, but this is not relevant. My point is that an implementation for a complex problem in a language with features to manage complexity will be more readable than an implementation for a complex problem in a simpler language.
* It sounds like we have both extensively used multiple programming languages but reached different conclusions.
> I don't think this is just a matter of taste. Advanced features allow the programmer to express more complex things more directly and less verbosely.
The fact that you and I disagree about how readable Go is should be evidence enough that it is a matter of taste. Otherwise we would be both agreeing that these facts lead the same outcome on readability rather than myself offering counterexamples to your points (and in fairness I don't disagree that you have well reasoned points even if I don't agree with your conclusion)
Here's another contradiction: Perl is often joked as being "executable line noise" because it allows you to express things in any which way you like and is antithetical to the very concept of verbosity. Yet these are properties you argue in favour of readability. So rather than verbosity+features having a boolean outcome on readability, I'd argue it's really more of a spectrum where (1) verbosity and (2) flexible grammar / descriptive features are axis on a graph. Somewhere in the middle will be a cluster of languages people consider readable - with some individuals preferring languages that scores higher or lower on one axis than another.
On the topic of verbosity, I've always thought the the language grouping (eg is it a higher or lower level language) gave a better approximation. For example Go does force some functions to be needlessly verbose however when taking your typical Go application and comparing it to the same thing writen in idiomatic Java or C# - languages I'd argue are in the same group - then Go doesn't actually come out all that badly at all. The problem Go has is the ugly areas of Go taints user perception for the other 90+% of the code (if it were as bad as some people express then I wouldn't waste my time with Go either).
Which ML do you mostly use for "general development"? Like simple tools, small web API's, etc? And what's the development/deployment story, compared to Go's (i.e. single .go file, easy (cross)compilation, single binary, pretty fast out of the box)?
I'm currently mainly using Go for these kinds of things, but I'm very interested in trying out an ML for this. I've tried Haskell but it seems very complex in a lot of cases.
Is most of the hype from a dev ops perspective? Go looks tiresome to program in.