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