Going through this, I now realize one of the significant reasons I took such a big liking to Go. They realize [1] how important it is to make it easy not just for a programmer to work with the language, but also for writing tools that work with the language. And this happens to be very important for what I do. [2]
>Rob Pike explains how Google designed Go to address major development issues they encounter while using other languages: long build times, poor dependency management, lack of robustness, etc.
So not exactly "Go at Google" (which is meant to give the impression this is all about how Google uses Go), but more like "How Go was initially thought out and built by a team at Google as a side project" or "How the team that built Go hopes to 'sell it' to Google".
About 30 mins into the presentation, Rob Pike does give a few examples of real Go usage inside Google. In the end he even mentions a few products that use it, like Youtube and dl.google.com
If I were charitable, I would say that the Go version supports horozontal scaling and external caching and queue buffers in a way that the BIND does not.
Those have been the 2 major products that use it for like 2 years.
One is a database load balancer (in YT), not the most essential or irreplaceable piece of infrastructure (ie. they can write it in another language whenever they want if the need arises without messing other stuff)
and the other is a services that was not updated anymore, and was left to die, before someone from the Go team asked and re-wrote it in Go. It's not even the full download service, just a part of it IIRC.
To be clear: a broken product that was actively annoying users and that no one knew how or had energy to fix, got fixed by a Go dev, and you are saying that is NOT a point in Go's favor?
Maybe if Reader were written in Go, it wouldn't have been killed.
>To be clear: a broken product that was actively annoying users and that no one knew how or had energy to fix, got fixed by a Go dev, and you are saying that is NOT a point in Go's favor?
Sure is a point in Go's favor. It means it can be used to solve an actual problem in a large company.
But what I'm saying is it's not that big of a deal as it may seem to some: it's not like they used Go in some highly critical for them infrastructure or important new project.
On the contrary: they used it at so low a priority project, that it was abandoned and left to rot before somebody volunteered (was not even asked!) to do the rewrite.
(And, no, it was not abandoned because it's C++ codebase meant it could not be fixed -- after all it could be redone from scratch in C++ or Java, as it was redone from scratch in Go. It was merely due to neglect).
So, my point it, this story is not a "investing internally in the language big time" thing, but rather baby steps.
You say the big company is not investing in a big way, I see a small team of revolutionaries rescuing a behemoth from crushing itself under its own weight. :-)
Rob Pike explains how Google designed Go to address major
development issues they encounter while using other
languages: long build times, poor dependency management,
lack of robustness, etc.
In any case, Google is heavily invested in Go. There's no need to "sell it."
There is very little evidence of that. The language is a few years old now and the only presentations are coming not even from random Google employees but exclusively Go team members. If Rob Pike wasn't involved in this language, it would be completely invisible.
So, there's not a lot of concrete evidence that Go has made any inroads inside Google against Java and C++ and from what I can see, the language is hardly every used outside Google as well.
I would like to see more internal Google stats as well but-
"and from what I can see, the language is hardly every used outside Google as well."
3 Months ago Go was more popular on github by number of unique committers than Lua, Clojure, Haskell, Erlang, D, OCaml, Lisp/Scheme, Rust, Delphi, Prolog, F#, Ada etc [1]. Surely you consider some of those languages as being relevant? That is not a perfect metric, but those stats don't fit your narrative of Go being unused very well.
>3 Months ago Go was more popular on github by number of unique committers than Lua, Clojure, Haskell, Erlang, D, OCaml, Lisp/Scheme, Rust, Delphi, Prolog, F#, Ada etc [1]. Surely you consider some of those languages as being relevant?
No, none of them is really relevant industry-wise at this point. That doesn't preclude them being excellent languages, used in a lot of projects, but the "a lot" for Haskell and even Clojure is some orders of magnitude less than the "a lot" for Java, C, VB, etc.
The listing has Java and Ruby head-to-head which is not at all the case, not even close, in programming at large. It's just that Ruby is more popular with the GitHub using type of people, whereas tons of enterprise programmers using Java can never put their source up there for all.
(The same listing has VimL and Emacs Lisp above of Go -- I guess people merely storing their Emacs configuration on GitHub are probably counted as programmers doing actual development work).
> If Rob Pike wasn't involved in this language, it would be completely invisible.
Being the last item on Ken Thompson's resume prior to his retirement makes it kind of visible, too.
> So, there's not a lot of concrete evidence that Go has made any inroads inside Google against Java and C++ and from what I can see, the language is hardly every used outside Google as well.
I did for over 5 years. While I left before the Go programming language was released, I seriously doubt they've transitioned much of the codebase to it, for one simple reason:
The Google codebase is fucking massive. I simply cannot describe how unbelievably huge it is, and while I don't doubt for a second that Go will be used for some of the systems-level projects (some of which Rob Pike is directly involved with - how's that for vague), you simply don't transition that big of a codebase to a new language.
It would basically be impossible... unless you're Jeff Dean.
Thank you. That's fair, but I think a better metric of the success of Go - which is how this train of thought started - would be how much new stuff is being started with it, for just the reason you stated. It'd be nutty to rewrite a bunch of working code.
In addition to the difficulty of rewriting existing code, even when you program something new at Google, you'd be a fool not to leverage what infrastructure already exists. If you try to do that while at the same time writing the new project in Go, you run into weird interoperability issues.
That's a good point, though protocol buffers aren't used for everything. There's more tightly-bound systems stuff going on, plus libraries and so forth. Which is to say, I have no idea.
a) It doesn't make a lot of sense for Random Google Engineer #62 to give a presentation about a small project.
b) Go, like every other programming language, will take time to get up to speed. Programmers need to be familiar with it. Managers need to be OK approving new projects to use it. Old projects will need a really good reason to get a rewrite in it. There is no edict at Google to use any given language, it just has to be one of the four blessed languages: Java, C++, Python or Go. Go has to prove its value against languages that are decades old with full library support.
So no, I wouldn't say that it is clear Go has made inroads at El Goog, because I don't think anyone reasonable would expect it to. Is it fair to say "Google is heavily invested in Go"? I don't know. I think it's fair to say Rob Pike and his team are very clever, and they're spending their time on Go, so that bodes well.
"Parent says only members of the core Go team are known to be doing stuff with Go in Google. But that is circular reasoning on his part, because anybody who makes something in Go also becomes a member of the core Go team (or he considers him one, anyway).
I don't think it holds.
The core Go team is more or less specific and stable over the years, and the news about projects and stuff usually come from certain core members (Rob, Brad, and 1-2 more).
Very rarely do they come from other, random guys at Google (the YouTube thing being the exception IIRC).
So it's not like Google has mass adoption from tons of Google developers but he dismisses it because they all are "just from members of the Go team" in his eyes.
And, of course, thinking a language is excellent and using it in your project, by no means necessitates you becoming a member of said language's core team. We don't see much rise in the Go core team members anyway (if any).
>Rob Pike explains how Google designed Go to address major development issues they encounter
Only Google never "designed Go" -- in the way it designed the V8 or Dart, SUN designed Java or MS designed C#, ie. assembled a team, funded them, and told them to specifically build a language as a project to fix some specific issues.
A team at Google designed Go on their own, as a side project, to scratch their own itches/pain-points.
For me at least, those are two clearly distinct cases.
Now, you can argue that the second, being grassroots and all, is better, or whatever, but I would not use the words "Google designed Go to address major development issues they encounter" for the second case.
Now, afterwards, the team got some funding from Google to work on it now, and Google even has added other people to work on it, but it was never "designed" by Google (ie as a company decision at large) to solve their pain points, and the language was never officially adopted by Google by some decree in the "teams, use that, it solves our pain points" sense.
As for heavily invested, I don't know. A few projects seem to use it, but mainly minor ones. A db balancer for YouTube, Google Downloads (which was "no longer actively maintained" before switching to Go, etc). Of course they could adopt the language more in the future, but as of yet I haven't heard of any heavy rewrites and main components done in it.
Not to mention that at some point Google was "heavily invested" in Wave too, and that didn't come out that good. Who's to say at some point during the regular spring cleaning they wont kill the funding for the Go work, to streamline their development story? I can even see them killing Dart at some point, if it fails to get any adoption in 3-4 years.
The most suprising part to me is that it doesn't support inheritance. I'm currently reading 'Object Oriented Design with Applications' by Grady Booch [1] and I noticed the following in the section 'Object Oriented Programming'
> …object-oriented programming (1) uses objects, not algorithms, as its fundamental logical building blocks; (2) each object is an instance of some class; and (3) classes are related to one another via inheritance relationships.
> …By this definition, some languages are object-oriented, and some are not. Stroustrup suggests that "if the term 'object-oriented language' means anything, it must mean a language that has mechanisms that support the object-oriented style of programming well. A language supports a programming style well if it provides facilities that make it convenient to use that style. A language does not support a technique if it takes exceptional effort or skill to write such programs; in that case, the language merely enables programmers to use the techniques"
>…if a language does not provide direct support for inheritance, then it is not object-oriented. Cardelli and Wegner distinguish such languages by calling them object-based rather than object-oriented.
Per this definition I wonder if Go might not be better labeled 'object-based.'
I come from C++ background, so by "direct support", I think he means a language construct that clearly shows the inheritance relationship, as in
Java:
public class MountainBike extends Bicycle
or C++:
class MountainBike: public Bicycle
From those links, it looks like in Go, you use an anonymous struct inside a normal class. I would call it "aggregation" or "containment" (or implicit delegation), not inheritance. It suggests "has-a" relationship rather than an "is-a" relationship. The Go's "syntax" for inheritance (if you can call that) is ambiguous, unlike C++ or Java.
I don't see any downsides to this though, could you enumerate any you can think of? For instance, I believe I an model relationships either way and accomplish the same thing with little to no difference.
FWIW, I think that removing inheritance is a major strength of Go. Interfaces and composition give you most or all of what you want and get you in a lot less trouble.
So Go has embedding not inheritance because SubClass is not an instance of SuperClass, there is no hierarchy, only composition.
BUT what you might not realize is that any method defined on SuperClass (and only defined on SuperClass) can be called on SubClass, but it operates on SuperClass data. This allows SubClass to use SuperClass to help it fulfil an interface for example.
This is similar to C++ in which base class methods are 'virtual'. Is there a way to stop this behaviour? Just thinking how non-virtual methods can be implemented then. C++ has a keyword, 'virtual', for switching this behaviour, but any analogue in Go?
You mean like final in Java? I don't believe there is. Go has a different way of handling OO and so far I have never needed "final". In Go embedding is not common and interfaces are used much more.
In Go, having final in an embedded struct affect the containing struct seems wrong IMHO- this would allow embeded fields to dictate the behaviour of things that embed them. I don't think most programmers would be happy with adding a field to a struct and as a consequence be prevented from implementing a given method signature.
Weird isn't it? Posts on a new-ish, interesting programming language on a site frequented by a large number of programmers with a penchant for new, interesting languages.
I read them a couple of weeks ago when I decided to take a look at Go,
and they were really helpful and eye opening to the problems it is trying to solve.