[dkarapetyan]

Notice the author would still rather use Swift when he's doing fun stuff. I get this sentiment and more than once I've wished there were more constraints in the language to mitigate the damage some kid with a chip on their shoulder could do but it says something about the psychology of programmers, "I know personally I'm good enough to do magical, wizardly stuff with all the cool stuff that Swift gives me but you, well, you need some training wheels so we're gonna use Go for this project".

I don't know about you but I'd rather work with people that understand the tools they are using and when it's OK to do fun stuff and when it is important to exercise restraint and "dumb it down" for the good of the team. Using the language to solve the problem of uneven programmer ability feels a bit off. It's something out of 1984. You can't say "great" in Go you can only say "good++".

[nl]

I have a rule when I make project technology decisions:

If we understand the domain and understand what we are building then we can afford to be innovative on the technology. If we are trying to be innovative in what we are building then we need to choose proven (aka boring) technology.

[lumpypua]

I liken this to Intel's "tick tock" development approach. If they're moving to a new microarchitecture they stay on the same process, and if they're doing a process shrink they use the same microarchitecture. Working out the kinks of a new process can be done with a microarchitecture that's solid, and vice versa.

Visually: http://www.adlinktech.com/solution/img/20131121-1.jpg

New domain => use known technology.

Known domain => play with new technology.

[dkarapetyan]

So you choose Erlang then for highly reliable and available network applications?

[kelnos]

I think by "proven" he's implying that it's proven to himself, that is, that he's familiar with it.

I kinda like that philosophy, and didn't realize that I somewhat adhere to it: I tend to try to keep to tools I'm familiar with when I'm solving problems that I know are new to me. It lets me focus on the problem and avoid thinking too much about the tools. But if I'm in learning mode or need to implement something I understand well, I'll often reach for a new tool just to play around with it or try something different.

[nl]

Yes, this is another aspect: I think there is only a certain amount of "new stuff" the brain can absorb in a given time period. You need to choose what to use that learning budget on.

[nl]

If I had a team who had built in Erlang before, then possibly. But there are numerous other platforms with a proven track record in that too.

Perhaps I could rephrase it as being conservative in my technology choices when building innovative products.

[tptacek]

That's not at all what the author said. A shop-made jig isn't "training wheels for the shop".

[enneff]

I don't think it's necessarily about mistrust of other programmers. It's more that we all have tendencies to over-engineer the small stuff, so with Go giving you fewer ways to do things you spend more time thinking about the job you're getting paid to solve.

[georgemcbay]

"I know personally I'm good enough to do magical, wizardly stuff"

In my experience really good developers don't see it like that, they see it more like the Brian Kernighan quote:

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

It isn't that they are worried that "lesser" programmers will make a mess using "clever" code, but rather they are worried how long it will take them to debug their own "clever" code, or just decipher such code they produced themselves in the future after they haven't looked at it in 6 months.

[dkarapetyan]

I agree but you can do that in any language. That's more a reflection of the programmer than the language.

[georgemcbay]

True, but what makes Go different than a lot of languages is that it basically guides you into doing things in the most straightforward way possible by making it a PITA not to do so (see: the unsafe package).

If you have an infallible sense of discipline then you don't need this sort of guidance, but given unlimited flexibility a lot of developers can easily lapse into fat-kid-in-a-candy-store mode regardless of their knowledge and skill level.

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

[Dewie]

> "I know personally I'm good enough to do magical, wizardly stuff with all the cool stuff that Swift gives me but you, well, you need some training wheels so we're gonna use Go for this project".

It could also be that he realizes that he is a PL snob/geek, and that makes him more likely to pick up and learn weirder/'more powerful' languages/paradigms. Other programmers (arguably most programmers) aren't PL geeks, not for a lack of ability, but for a lack of interest. Choosing to use more advanced languages may be great for him, but may just cramp the style of other people that aren't PL geeks.