Some people see languages as a bag of features (immutability! generic programming! laziness! operator overloading! algebraic types! hindley-miller type inference! pattern matching! exceptions! manual memory management!). See http://yager.io/programming/go.html for an example of that line of thinking.
Those people won't get Go.
Designing a language is not about cramming every feature you can think of. It's about making good trade offs.
A trade off is: you get something but you also loose something.
I use Go because it made the biggest number of good trade offs.
Or to put it differently: I program in Go because when writing code, it irritates me less than other languages.
If you want a longer explanation of that: http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
This line of thinking serves more to call in to question the engineering and management cultures we have than it does to reflect poorly on Haskell and Erlang, and if it's true that Go's essential strength compared to them is that it is well-fitted to these cultures, that's not particularly flattering, however locally practical it may be.
If people disagree with you, your default assumption should be that they are looking at different evidence than you, not that they are incompetent or stupid.
Maybe Go is fitting into the cultures that succeed, and if that's the case, well it's the better choice, right?
We are. WhatsApp generated a flurry of interest around Erlang. Heroku uses it. I'm sure there are more examples.
Google is at this point already a large corporation and probably already in decline (IMO). The tools they use are optimized for interchangeability of mediocre programmers, not for high productivity from a small team. Go is a perfectly good Java 1.4.
(There's Docker using Go, but I think their whole approach is a bad idea).
Like these?
https://www.haskell.org/haskellwiki/Haskell_in_industry
https://www.erlang-solutions.com/industries
“I like a lot of the design decisions they made in the [Go] language. Basically, I like all of them.” – Martin Odersky, creator of Scala.
I don't think anyone would accuse Odersky of being a "blub programmer."
"Beating the averages" is not a very good essay, I don't think you need to drag it in here.
But to call someone a "blub programmer" does come off as quite rude.
Do I as a Go programmer sometimes wish that Go had feature X. Of course I do! I want that feature when I want that feature. But, I find Go to occupy an extremely practical position in my personal programming language continuum do to its fairly unique mix of features. Note, it is not the features themselves that are unique many languages individually have them. Indeed, they often also include features I miss in Go. Rather, it is the particular mixture which is useful.
EDIT: To respond directly to the Blub article.
Features pg calls out for LISP:
Garbage collection, introduced by Lisp in about 1960, is now widely
considered to be a good thing. Runtime typing, ditto, is growing in
popularity. Lexical closures, introduced by Lisp in the early 1970s, are
now, just barely, on the radar screen. Macros, introduced by Lisp in the mid
1960s, are still terra incognita.
Garbage Collection [x]
Runtime Typing [p]*
Lexical Clusures [x]
Macros [ ]
* Go has some dynamic typing capabilities but nothing like Python or LISP.
Many would consider that a "good thing". It partially depends on what you
are doing.
I can't speak for pg, but Go has many fantastic features and is not a Blub. The features which are missing are not, by and large, features of LISP.
EDIT 2: To add some more fuel to this fire...
pg concludes the article with:
During the years we worked on Viaweb I read a lot of job descriptions. A new
competitor seemed to emerge out of the woodwork every month or so. The first
thing I would do, after checking to see if they had a live online demo, was
look at their job listings. After a couple years of this I could tell which
companies to worry about and which not to. The more of an IT flavor the job
descriptions had, the less dangerous the company was. The safest kind were
the ones that wanted Oracle experience. You never had to worry about those.
You were also safe if they said they wanted C++ or Java developers. If they
wanted Perl or Python programmers, that would be a bit frightening-- that's
starting to sound like a company where the technical side, at least, is run
by real hackers. If I had ever seen a job posting looking for Lisp hackers,
I would have been really worried.
Python Score Card
Garbage Collection [x]
Runtime Typing [x]
Lexical Clusures [x]
Macros [ ]*
* It is somewhat possible through black magic hackery to create an AST level
macro in Python. It is messy. It is cool. It's kinda crunky. And I am not
sure anyone has ever seriously used this ability. It certainly isn't main
stream. Checkout https://github.com/lihaoyi/macropy for inspiration.
Therefore, I believe pg would have been equally worried or almost as concerned about Go programmers as Python programmers.
Rust doesn't do that. Rust expands the macros at compile-time. Integrating the whole compiler into the runtime wouldn't make much sense considering what area Rust is targeting.
It's also recommended to not link a crate that is used during runtime with the compiler or parser because they're fairly big and would bloat your final build by a large amount.
No, that's not necessary at all, with Rust-like macros which are simple pattern->template things. Macros have zero runtime cost.
You may be a victim of the Blub paradox. There are many useful and powerful features missing from languages like Go, and many of them (like powerful type systems) exactly address human mistake-making.
Indeed. And the hallmark of the really good design is to examine the interactions of those features and see how well they mesh together. And what they imply about how actual programs are designed and maintained.
And remember not to equate popularity with quality. We're all using JavaScript because that's what you need to do in the browser, not because it's a particularly good language. (Not that Go doesn't deserve the adoption it's gotten. It's great to see people ditching clunky Python/Ruby/C++/JavaScript stuff for Go.)
This is how I feel too. There are countless styles of prose, but some styles are restricted deliberately for aesthetics or practical reasons. I prefer to write prose in plain terms, and Go enables me to write code the same way. Some languages more than others have parts that stick out in odd ways, and add unwelcome personality to my code.
Yet sometimes I wish to put higher concepts into abstract terms, and Go is less expressive here. You can't always shape things the way you want, and you can't build reusable parts with the same flexibility as in other languages. But, when it comes to tinkering and giving form to ideas, I am more productive working with a basic set of LEGO than a box of all the specialized pieces someone may have thought I might ever find a use for.
Because Google.
In longer form, because Google is big and Go is well-enough-adapted for problems Google has (there may or may not be better solutions, and there may be some NIH factor going on in Google favoring it, but its at least good enough), and because the fact that Google is big and behind Go, that gets it lots of attention and interest and use even in places where it may not be as well suited as alternatives or what it is replacing.
Programmers liking confortable algol like syntax, and Google pushing it?