

Go at Google [video] - DanielRibeiro
http://www.infoq.com/presentations/Go-Google

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

~~~
mseepgood
Or the article: <http://talks.golang.org/2012/splash.article>

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

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

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

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

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

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

~~~
voidlogic
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>

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

~~~
chmike
Today or in 10 years ?

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

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

------
cgcardona
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&...](http://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=0805300910)

~~~
zik
It does have inheritance although the syntax is different:

    
    
      type SubClass struct {
        SuperClass
        other fields...
      }

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

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

is valid.

~~~
voidlogic
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_>

~~~
shared4you
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?

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

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

~~~
voidlogic
<http://en.wikipedia.org/wiki/Final_%28Java%29#Final_methods>

------
brianpgordon
> The dependencies have to be a true tree.

Surely he means DAG?

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

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

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

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

