[kjksf]

You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer.

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...

[wwweston]

> You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer.

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.

[AnimalMuppet]

That sounds almost like denial to me. "If everybody doesn't adopt what I think they should, it has to be because they're dysfunctional! It can't be because the stuff I like is less generally applicable than I think it is!"

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.

[jshen]

If languages like Haskell and Erlang gave a competitive advantage, wouldn't we see companies which used them succeeding over those that don't?

Maybe Go is fitting into the cultures that succeed, and if that's the case, well it's the better choice, right?

[lmm]

> If languages like Haskell and Erlang gave a competitive advantage, wouldn't we see companies which used them succeeding over those that don't?

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).

[jshen]

You are seeing companies that use those languages suceeding at a higher rate than those that don't? I bet I can find 10 succeeding that use ruby or node for everyone that uses Erlang.

We could also look at the open source world. For every riak there are 10 java sucesses of a similar kind.

We'd need to do some real statistics but my bet is that we see no benefit from those languages in terms of success of the business.

[lmm]

> I bet I can find 10 succeeding that use ruby or node for everyone that uses Erlang.

But that's not the question, is it? There are a lot of companies succeeding with ruby or node, but also a lot of companies failing with them. I'll bet the strike rate is better for Erlang companies.

[jshen]

Il bet that the choice of language has no impact on success.

[pjmlp]

> If languages like Haskell and Erlang gave a competitive advantage, wouldn't we see companies which used them succeeding over those that don't?

Like these?

https://www.haskell.org/haskellwiki/Haskell_in_industry

https://www.erlang-solutions.com/industries

https://ocaml.org/learn/companies.html

http://fsharp.org/testimonials/

[codygman]

The stock price of Standard Chartered is 939 GBX currently.

[wcummings]

I get the impression some of the folks in the Golang crowd are "Blub" programmers [1]. It's not so much a matter of simplicity and trade-offs as it is a matter of "I don't need things I don't know about", which isn't a good argument to use Golang.

[1] http://www.paulgraham.com/avg.html

[enneff]

Most Go programmers I know, including the language designers themselves, have a lot of experience in more feature rich and expressive languages. What appeals is the simplicity of Go, which gives you a lot less of a language to think about, so you can just think about solving problems instead.

“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."

[jeremyjh]

Martin has something nice to say about everyone's project. I seriously doubt he likes that a new language was created in 2009 that allows null references. But we'll never hear about it if he doesn't. Still, that doesn't make him a Go programmer.

[tree_of_item]

This is a great way to insult a bunch of people and start a fight.

"Beating the averages" is not a very good essay, I don't think you need to drag it in here.

[djur]

"Blub" as a concept isn't really useful anymore. I've seen people attacked as "blub programmers" for criticizing Go for its lack of features. At worst it's a personal attack ("you are a short-sighted programmer"), at best it's kind of supercilious ("language X is great, it's just over your head").

[Dewie]

I think "blub" is just another example of "you don't know what you don't know", which is always going to be relevant. And not everyone have tried, or intend on trying, obscure/sophisticated/mind-bending programming languages. And that's fine, since we all have different interests (as long as we don't try and pretend that we are very knowledgeable about something which we don't really have an interest in pursuing).

But to call someone a "blub programmer" does come off as quite rude.

[timtadh]

I feel like you haven't met a lot of Go programmers in that case. The programmers I have met who use Go or are interested in it are often genuinely good programmers. Of course there are "crowd" followers in any language as popular in Go but Go is not a "Blub" language nor does it attract Blub programmers.

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.
 

Go score card:

    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.

Go has a 3/4 on the score card of features. Macros are of course enormously useful but also very difficult to shoe horn into a c-family language properly since they need to be expanded at compile time (unless you just go ahead and embed you compiler backend into the runtime system of your language. That would be kinda of crazy/awesome but you could do it). Rust has of course proven the utility of such a choice.

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.

Note, he explicitly says here: not all languages are the same. He would worry when a company wanted Python programmers. Why? Because to him Python mixture of features represented a nice chunk of what LISP is providing him. Let's do another score card:

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.

Norvig agrees with this assessment: http://norvig.com/python-lisp.html . Given that many people are ok with moving from Python to Go <https://www.reddit.com/r/golang/comments/2aup1g/why_are_peop... it seems reasonable to conclude that Go is an exceptible replacement for Python. Something no one has concluded about Java (for instance).

Therefore, I believe pg would have been equally worried or almost as concerned about Go programmers as Python programmers.

[TheHydroImpulse]

> Macros are of course enormously useful but also very difficult to shoe horn into a c-family language properly since they need to be expanded at compile time (unless you just go ahead and embed you compiler backend into the runtime system of your language. That would be kinda of crazy/awesome but you could do it). Rust has of course proven the utility of such a choice.

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.

[timtadh]

yep. I never meant to imply that rust macros were expanded at runtime. I was trying to use rust as an example of a c-style langauge with a nice macro system.

[lmm]

Actually, to be a little more constructive about this: I'd be really interested to hear from anyone who's used Go after doing a serious project in any of Haskell, Scala, F# or OCaml. All the Go advocacy I read seems to ignore that this language segment exists, and all the Go programmers I speak to seem to take a very "blub" position on features like pattern matching, ADTs, and the various things I'd summarize as "good type systems". So it would be great to hear from someone who's used these things seriously, understands their advantages, but still thinks Go is making the correct tradeoff.

[timtadh]

I use Scala at work. I would rather write in Go than in Scala. While there are many things to like in Scala there are also many misfeatures such as the `implicit` key word which can create a lot of spooky action at a distance. Scala is an engineering tour de force and has many interesting ideas. However, I find that it has too many features and has a syntax with encourages obscure code. In contrast Go may be verbose at times but it is always very easy for me to read and follow.

I recently needed to dive into a legacy Scala code base which had not been worked on in a year. The engineer who had written it had moved on from the company and no one knew how it worked. The code was extremely difficult to read and reason about. Some of this was do to the programmer who wrote it but some of it was also do to language features. Is it possible write clear and concise Scala? Absolutely! But, the language does not necessarily encourage that style at this time.

Other functional languages I have used include: Scheme and SML. I want to check out OCaml next. I have also played around a bit with F* (not F#).

[lmm]

Languages without decent compile-time type systems are pg's own blub.

[vorg]

pg writes about macros as the top of the blub ladder whereas you mention compile-time type systems, but I'd say it isn't a ladder but a twin-peaked hill, i.e. strongly-typed lazy functional code (e.g. Haskell) and dynamically-typed variadic homoiconic code (Lisp). They have an "impedance mismatch" such that they don't inter-translate very well, unless they use clunky addons like Template Haskell macros or Typed Clojure annotations. The pure form of each language, however, is based on two mutually exclusive foundations, i.e. strongly typed auto-curried parameters vs variadic untyped macro parameters.

The strong typing and lazy evaluation of Haskell makes it easy for functions to take only one argument at a time. Although a function could take a tuple parameter, it is usually rewritten to take each component of the tuple as a separate parameter, which makes the strong typing and built-in currying simple, higher structures like monads possible, and a syntax to suit this style. Lisp functions and macros, on the other hand, must be variadic to enable the homoiconicity of the language. It's therefore much more difficult for parameters to be typed, or to curry them. The syntax requires explicit visual nesting.

The poster child of each style, monads and macros, are thus two peaks in language abstraction simply because of these different required foundations of each, and if you, lmm, have achieved Haskell-style enlightenment, then dynamic variadic homoiconic languages are your blub.

[lmm]

I use scala so I have both (somewhat clunky) macros and types. I am not unaware of the costs of clunkiness or the merits of the lisp approach, and I have not stopped looking for a language that can combine both advantages - in contrast to pg, who seems to dismiss the value of strong types without ever having used them seriously.

[AnimalMuppet]

You're right, but don't assume that there are only two peaks. That's making the same mistake you're arguing against.

[eudox]

>Macros are of course enormously useful but also very difficult to shoe horn into a c-family language properly since they need to be expanded at compile time (unless you just go ahead and embed you compiler backend into the runtime system of your language.

No, that's not necessary at all, with Rust-like macros which are simple pattern->template things. Macros have zero runtime cost.

[timtadh]

I totally agree I made this point badly.

[cbp]

Some people look at a new language and don't see anything that proves it was made after the 1970s.

[zzzcpan]

And I hope it stays that way. We don't need more features, we need to address psychological issue of mistake-making.

[wyager]

> We don't need more features

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.

[zzzcpan]

No need to get personal. I was talking about all the features in all the languages, not the ones in Go. And yes, we don't need more new features, we have plenty.

However, none of the languages I know of address psychological issues. Does type system reduce mistakes or introduce? Certainly both, don't know which one more though. But the question itself is wrong. It's not the type system who makes mistakes, humans do. And humans have brains. And brains are limited in their ability to do some thing while keeping other things in mind. And if among other things types happen to be present and mistake was made, than one could say types added to that mistake. And if types were not something programmer needed to think than type system certainly didn't add to that mistake. Things are not as simple as most programmers tend to think. Features don't matter how they think they matter. And research in language design was broken since the beginning of times and, sadly, still is.

(if you read "no silver bullet", "out of the tar pit" papers and couple of recent ones on bugs you should get the idea of how bad things are with mistake-making research)

[tomp]

How does a type system introduce mistakes? Unless it's unsound, of course (as is Java's and Dart's).

[samth]

Java's type system is sound. There are even machine-verified proofs of this.

[f2f]

well, rust has all those powerful features. it's been out in the open for exactly as long as Go has.

[djur]

Rust isn't nearly as stable as Go. It still hasn't reached the state that Go was in when it was released outside Google. That's not a judgment of Rust, just a result of it being developed in the open instead of inside a company, and it being much more ambitious than Go.

[davecheney]

Go was released as an open source project on the 10th of November 2009. Which part of that is _not_ open to you in a way that Rust is ?

[Dewie]

Rust 0.1 came out in the beginning of 2012, about 3 months before Go 1.0 game out (or go1). In the meantime, Rust has changed a lot and is only now close to a 1.0 release.

[dbaupp]

FWIW, Rust has been on github since June 2010.

[ansible]

Designing a language is not about cramming every feature you can think of. It's about making good trade offs.

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.

[thirsteh]

While I agree with these arguments, the purpose of Go is to Get Stuff Done (TM), and the main purpose of Haskell is to foster PL research and semi-formal methods. It's not really fair to say Haskell is unpopular because it crammed a bunch of things inthere: It is very popular in the niche it was designed for. Go just has a wider appeal.

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.)

[macu]

> I program in Go because when writing code, it irritates me less than other languages.

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.

[dragonwriter]

> You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer.

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.

[coldtea]

>You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer.

Programmers liking confortable algol like syntax, and Google pushing it?