[zackbloom]

So you're saying you want programming to be hard because that means you get to work with smarter people? I think what Go is striving for is simplicity, not elegance. And that change makes the code easier to write and maintain for everybody involved. At 10AM I might feel like writing Swift, but at 3AM I'm sure as hell glad I used Go.

Or, less anecdotally, I maintain about twelve services in Go, including web services, proxies, and an analytics engine, and I have never been woken up in the middle of the night with a failure. That was certainly not true when I was writing Python or Javascript. Erlang or Swift might offer comparable reliability, but it comes at the cost of a lot of complexity.

[MCRed]

When things get serious, I think you'll discover that Go provides far less reliability, and is far more complex. (What's simpler than "it's already handled for you with OTP and battled tested for 2 decades"? That's a lot more simple than "you can't do it in this language and you'll end up with a poorly implemented half version of OTP in Go."

Of course for toy or small services, go is fine. Erlang certainly could use the "build a binary run it anywhere" distribution model of Go tool.

But reading all these pro-go articles, it strikes me that none of them seem to be written by people who really understand concurrency.

Believe me, I wish Go was written by people who had understood erlang. There's a lot to like about it and it has momentum.

[bojo]

I'm not sure YouTube or dl.google.com qualify as "toy or small services", nor the handful of other relatively large businesses building on top of Go (CloudFlare, Iron.io, etc).

[lmm]

I don't think anyone disagrees that Go is an improvement over Javascript, or more reliable than Python. But I've been working in Scala for several years and could say the same thing about never being woken up.

Look at the examples on the page. Would you really rather see the Go one at 3AM? It's twice as long, and the superficial similarity of each if(err...) stanza obscures the important differences. On a large codebase that adds up. Maybe the "complexity" meant the Swift took longer to write (though I'd dispute that too) - but if it's more readable and more maintainable, that's a positive tradeoff.

[dkarapetyan]

Define what you mean by hard and then I can say whether you're correct or not. Otherwise you're putting words in my mouth. I didn't say I want programming to be "hard" but I did say I'd rather work with smarter people. That doesn't mean smarter programmers exclusively program in Haskell, Erlang, Clojure, Scheme, Racket, SmallTalk, etc. I find programming overall to be quite easy in any language once you're used to thinking with the abstractions the language offers. The hard part is communicating with other people.

Also, your "less anecdotally" is by definition pretty anecdotal.