[anon01]

We've just started using Go as well. It smokes our Python app in terms of speed, and is fun to use (maybe just because it's new?).

I have always wondered, however, that if moving to a new language seems great because of the language, or because you have such a better understanding of the implementation of the problem you are trying to solve.

[agentultra]

You bring up an interesting point about "new."

New is fun. Exploration is fun. I think a lot of people will swear by a new language simply because it's not old and probably doesn't suffer many of the same deficiencies they're used to in their "every day," language.

This to me is an illusion however. One must remain skeptical and treat new, untested languages with even more scrutiny than an old one. Many of these new languages will make extraordinary claims. Discovering the evidence to support these claims is often left as an exercise to the programmer.

That being said, new has a lot of advantages. It's free to try to break away from past paradigms that perhaps limited programmers. Stability can always come later once the core ideas have been fleshed out. And it's always fun to work on fresh ideas rather than refining the same old ones that we're plagued with.

Personally I wouldn't use a language and compiler that only just reached 1.0 this year in a production system. If I was really interested in Go I'd certainly hack with it and perhaps on it, but I wouldn't trust it to be reliable. Maybe that makes me an old, stodgy fart but I trust wisdom over brilliance when it comes to building systems that are dependable and robust.

[luriel]

Go has been surprisingly reliable and stable, even before it hit 1.0 a few months ago quite a few people (including Google) were using it in production: http://go-lang.cat-v.org/organizations-using-go

With Go 1.0 there is an even greater focus on stability: http://golang.org/doc/go1compat.html

Go is also quite different from most 'new' languages, many people find it to be the most fun language they have used in a long time (even after using many other new languages).

This might be in part because one of the things that makes Go special (and my favorite "feature") is not just the features it has, but all the stuff it doesn't have.

Go is simple and doesn't get on the way and lets you focus on the problem, other "new" languages are often described as "powerful", but much of the work involves using their "features", when Go is more often described as productive, the focus is not in the language and its features but on the problem you are trying to solve and the language gets out of the way.

[icebraining]

Is it really helpful to judge a language by its version number? Go is a very conservative language, in that it only uses well known and studied language features, and has been in production at many companies, including Google, Canonical, CloudFlare, etc.

Certainly it deserves more faith than any random language designed for the exploration of new paradigms and features and which is only used by its maker?

[Lewisham]

To paraphrase Big Lebowski: "Well, like, that's just Google's opinion, man."

Of course Go is already in production at Google because the Go team designed it to fit particular pain points that Google was having, so it's going to have the libraries that are needed to solve those problems. The question is whether the current libraries are there to solve your problems, and, as others noted, it's not that cut-and-dried.

[anon01]

Version numbers are pretty useless these days. I would certainly put a lot more stock in a 1.0 from the Go team than, say, my company. We use version numbers more for marketing than anything else.

Personally, I'm not as worried about reliability as I am roadblocks. Say, for instance, we spend a month moving our framework over to Go. Then we find a problem that is yet unsolved. Either we solve it ourselves at an unknown cost or we have to just ... wait.. until another group solves it while we make payroll in other ways.

I'm lacking any real evidence here, maybe Go doesn't have a library for our Message Queue (not true, just an example). Now we aren't just porting, we're writing a pooling message queue interface that is beyond our pay grade in the language.

[duggan]

  > spend a month moving our framework over to Go

Seems a little extreme. Just use it for small, discrete projects. No need to bet the farm.

[jlouis]

New vs Better is also an interesting point. In this case, Go is a leap forward from Python in terms of language quality and predictability. It even provides you are proper concurrency framework - something all modern languages need.

[pjmlp]

> It smokes our Python app in terms of speed

Like any other compiled language would do.