Go at Google [video] | Hacker News Reader

Go at Google [video]

infoq.com

143 pointsDanielRibeiro58 comments

You can just check the slides here: http://talks.golang.org/2012/splash.slide

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.

Or the article: http://talks.golang.org/2012/splash.article

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]

[1] http://talks.golang.org/2012/splash.slide#34

[2] https://github.com/shurcooL/Conception#conception

> but also for writing tools that work with the language.

What I've seen from go's tooling today: a very crude debugger and zero IDE support.

The bar for "good tooling" in 2013 is quite a bit higher than it was in 1999.

IDE support comes in the form of the gocode daemon. Works fine with Emacs, Vim, Eclipse, etc.

There's a Golang-specific IDE but it isn't very fancy. Most people just use the Gocode daemon with their editor of choice.

>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

Not to mention Google Public DNS http://wilmer.gaa.st/blog/archives/58-Google-Public-DNS.html...

"While BIND (written in C) can only serve 1000 queries per second on an old 486, the Go rewrite can serve all DNS queries in the world"

Maybe I mis-read it, but that comment comes across as a little sarcastic. Hope I'm wrong.

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

This is the summary at the top of the page:

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

> In any case, Google is heavily invested in Go.

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.

1: https://gist.github.com/igrigorik/4440674

I doubt GitHub reaches at all 1% of the code developed in all companies in the world.

Today or in 10 years ?

1 - Except for open source startups, companies only use internal repositories;

2 - Many are still using centralized repositories like cvs, svn, clearcase and TFS

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

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.

> I think it's fair to say Rob Pike and his team are very clever

Rob's cleverness and contributions to computer science are indisputable, but that doesn't make him a good language designer.

From what I've seen of Go, it seems like it was designed by a team that stopped looking at other programming languages in the late 90's.

Late 90's is being gracious to a language that smells like an ALGOL and Pascal cross-over.

Leaves me to wonder why some of these people bothered with C to begin with and didn't just use Pascal. Momentum in the Unix world maybe?

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

Do you work at Google?

> Do you work at Google?

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.

Do you know whether Go is compatible with Google infrastructure? With protobufs and stuff like SwIG/JNI, why would it not be?

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.

>Being the last item on Ken Thompson's resume prior to his retirement makes it kind of visible, too

In the way Plan 9 got mass adopted?

Do lots of people know what Alan Kay does now? Or what was McCarthy's last project?

Accidental NoTrueScotsman alert.

If a Googler thinks Go is awesome and builds a bunch of stuff in Go, what happens to that Googler? They become member of the core Go team!

If I understand correctly, your argument is:

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

> In any case, Google is heavily invested in Go. There's no need to "sell it."

Really?

That is why Go is part of the standard Android SDK/NDK. Oh wait!

That is why Go is part of the NaCL SDK. Oh wait!

That is why I can have first class treatment for all Google APIs with Go. Oh wait!

Is the last one less than at least 90% the case?

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

[1] http://www.amazon.com/gp/search?index=books&linkCode=qs&...

Define "direct support" for inheritance. IMO, a symbol named inherit doesn't have to exist for there to be inheritance.

Here is a blog post answering your exact questions: http://areyoufuckingcoding.me/2012/07/25/object-desoriented-...

Here are examples of inheritance in Go: http://golangtutorials.blogspot.com/2011/06/inheritance-and-... http://diveintogo.blogspot.com/2010/03/classic-inheritance-i...

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.

Inheritance is implicit delegation, in any language. The "implicit" is what makes it inheritance.

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.

It does have inheritance although the syntax is different:

  type SubClass struct {
    SuperClass
    other fields...
  }

Embedding is not strictly the same thing as inheritance.

That is not inheritance, it is embedding: http://golang.org/doc/effective_go.html#embedding

So, according to this logic, even C is Object-oriented with support for inheritance, because:

     struct SubClass {
        struct SuperClass super;
        // .. other fields ...
     }

is valid.

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.

See it in action: http://play.golang.org/p/8kiwu1PlW_

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.

Ah sorry, I have no idea about Java or final, so ... can't comment.

http://en.wikipedia.org/wiki/Final_%28Java%29#Final_methods

Go try calling SuperClass's method on Subclass, and tell us the two problems you face.

I don't think you really understood the Go example. In C if I have:

    struct SuperClass {
        int foo;
    };
    struct SubClass {
        struct SuperClass super;
    };

Then to set the foo item I'd have to do: struct SubClass bar; bar.super.foo = 5;

Whereas in Go I could say: type SuperClass struct { foo int } type SubClass struct { SuperClass } bar := SubClass{} bar.foo = 5

So, small difference, but I think valid.

> The dependencies have to be a true tree.

Surely he means DAG?

I believe you are correct. Otherwise you could only import each package once during the whole project, right?

The masochistic side of me is now interested in trying to build a project like this...

Have you tried java? Let me show you my TimeDateAccessObjectFactory.

Daily post on go.

Go and its advertisement campaign have something in common: lack of subtlety.

I will eat my hat if tomorrow I don't see another go post.

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.

Reply on news.ycombinator.com