[eta_carinae]

I was having lunch with a friend of mine who works at Google a few weeks ago and I asked him how popular Go was at Google. He said the only people using it are the Go team. Java and C++ continue to reign supreme at Google.

[enneff]

Your friend is out of the loop. I am one of the Go readability reviewers, and I review thousands of lines of Go code each week. The code is written by Googlers from different teams around the world.

It is true that Go is in the minority compared to C++ and Java. Change takes time at a company of this size. But the graphs are all up and to the right, and the rate of Go code being written at Google is accelerating.

[eta_carinae]

> I am one of the Go readability reviewers, and I review thousands of lines of Go code each week.

If you're on the Go readability team, you are going to see thousands of lines of Go code each week, as a simple consequence of selection bias. Your observation doesn't invalidate my friend's claim.

Something that would invalidate that claim would be how many lines of Go are submitted into the Google code base every week compared to Java and C++. My friend is simply saying that this ratio is minuscule.

[kenko]

His claim is still an effective denial of the claim he was denying, namely, that the only people using Go are on the Go team.

[quest88]

Of course it is. There are a ton of existing projects in those languages.

[jlouis]

Let me add: more powerful and expressive languages can often get away with far fewer programmers. So if you measure in sheer numbers of people working on, or lines of code being executed, you get the wrong number count.

A rough estimate from Erlang, is that the typical Erlang program is 1/5th of the typical C++ program implementing the same functionality. And the Erlang program even handles unforseen events :)

[beagle3]

> A rough estimate from Erlang, is that the typical Erlang program is 1/5th of the typical C++ program implementing the same functionality.

And taking that to the extreme, J/K/APL is usually 1/100th of the typical C++/Java program implementing the same functionality. Unlike erlang, it's not more robust - but it's often faster (not because of some theoretical advantage - when you write 1/100th of the code with the right primitive, you have more time to think about optimizing it)

But as another poster said: Shh, don't tell anyone about our unfair advantage.

[oinksoft]

Ssshh, don't talk about Erlang/OTP too loud, they might realize how good it is ;)

[jlouis]

My stance is still the same as two years ago: Golang is a very decent language with a lot of interesting features. But the lack of direct address of fault-tolerance is what I am missing. In distributed systems, you can't hope to handle all kinds of failure scenarios. You have to punt at some point and assume that the problem doesn't ever happen in the real world. And that is where you need fault tolerance.

[codewright]

It's not really common or standard to rely on a cluster of VM instances to solve your distributed problems for you these days.

For most programmers: Statelessness is the default, replication and fail-over are the back-up plan.

Talking about Erlang's "fault tolerance" as if it's some sort of secret weapon these days (it was more important 10-20 years ago) is a canard and distracts from the better parts of Erlang.

[pjmlp]

So when do we expected it listed as an official Google language?

[Symmetry]

It already is.

[pjmlp]

I fail to see it like that.

It is not listed here:

http://google-styleguide.googlecode.com/svn/trunk/

These guides are much more than just what gofmt does.

In a Google IO conference talk someone stated that the Google App Engine support was actually made by the Go team.

Not all new APIs released by Google tend to offer Go APIs as well from day 1.

So I miss the official language support that you say already exists.

[enneff]

Google had four canonical languages: C++, Go, Java, and Python. They are defined internally in an engineering handbook. There is no such similar style guide for Go, as a a lot of what the existing guides say is "don't use x." If that were needed for Go we would have failed.

[pjmlp]

Fare enough.

> If that were needed for Go we would have failed.

Why? Even with Go there are many ways to do certain things.

I can imagine given the language's youth not everyone would write the code the best way.

I know the few times I did some Go coding, I was most likely not good enough to the canonical style.

[stock_toaster]

I imagine the Go style guide would also largely boil down to 'use `go fmt`'.

[sigzero]

You pretty much agreed with his friend.

[enneff]

No I did not. The friend said that nobody outside the Go team uses Go. My post indicates that the majority of Go code at Google is written by people working on other teams.

[Symmetry]

Well, one of my friends who works at Google is using Go for whatever project she's working on.