
Rob Pike: Go at Google - jbarham
http://talks.golang.org/2012/splash.slide
======
tikhonj
What annoys me a little bit about Go (and other projects similarly adherent to
"worse is better") is the implied dichotomy between "research" and making
"programming lives better". Do they think the point of Haskell isn't to make
programming easier? That's what most of the research into the language is
_exactly_ about! This isn't just about Haskell either: most other PL research
is also about making programming lives easier. And Go ignores essentially all
of it.

Now, there is even nothing strictly wrong about ignoring research like that.
It's just annoying how they _revel_ in ignoring all recent progress in the
field.

~~~
cageface
Haskell is an elegant language but Haskell fans will be much more effective
advocates of the language if they admit that it's conceptually very difficult
for most programmers to grasp. Some of the most experienced and capable
programmers I've ever known have struggled to get their head around Haskell,
and I don't buy the argument that it's only because their minds have been
poisoned by overexposure to other languages.

Haskell is important and I'm glad it exists but I think Go has a much better
chance of become a plausible alternative to Java and C++ and perhaps Python in
most programming shops.

~~~
Raphael_Amiard
I think Simon Peyton Jones says it best about Haskell :

<http://www.youtube.com/watch?v=iSmkqocn0oQ>

He says Haskell is useless. Without even debating that (it can certainly be
useful for certain classes of programming problems), you can see his point :
The goal of Haskell was to start from an ideal view (pure functional
programming without side effects) and try and see how to make that eventually
practical for everyday programming, _without sacrificing the pure core of the
language_.

You have languages, like F# (or even C# !) that takes lessons from Haskell,
with at the same time being practical for pretty much every programming task
(their platform , .Net, makes them useless for a lot of use cases, but that is
another problem)

And on the other side (in my opinion), you have languages like Go, being
pretty dismissive about pretty much everything learned from languages like
Haskell.

I respect the point of view of Go's creator, i just disagree with it, and
don't see any project i could do in Go that i wouldn't prefer doing in
Scala/OCaml/C#. But more power to people who want to do great things in Go !

Go fills a niche (AOT compiled without a VM) that only OCaml fills in the list
of languages i have listed, and OCaml is probably much more complicated to
learn, even if it is way simpler than Haskell, so even if i don't agree with
the design choices, i can see why Go could gain traction (apart from the fact
that it is Google powered)

~~~
kenko
Peyton-Jones said that Haskell was useless before they got a handle on how to
do IO. Haskell is clearly not useless at present.

~~~
meaty
However it's far harder to make it not useless than other choices. To me at
least, Haskell appears to be alphabet soup like badly written Perl. The syntax
is so close to the metal it's unreal.

~~~
pcwalton
SPJ's comment had nothing to do with lexical syntax.

------
eternalban
<http://talks.golang.org/2012/splash.slide#48>

Time for honesty: What bullshit.

\- Go codebases by non experts are peppered with magical incantation (sleeps,
etc.) to avoid the dreaded "all goroutines are sleep". Of course "they are
doing it wrong", but that is the germinal point.

\- A concurrent Go program will likely behave differently given 2 bits (just 2
lousy bits) of difference in the object binary. (runtime.GOMAXPROCS(1) vs
runtime.GOMAXPROCS(2)). Imagine someone touching those 2 bits in a "large
codebase". It is practically impossible to do the same thing in a large Java
codebase and fundamentally change the programs runtime behavior. (Happens all
the time in Go.)

\- It is very difficult to reason about a Go routine's behavior in a "large
codebase" without global view and a mental model of the dynamic system e.g.
which go routine is doing what and who is blocking and who is not. Pretty much
defeats the entire point of "simple" concurrency, to say nothing of "scaling".
Programming in Go's variant of cooperative multithreading is actually more
demanding than preemptive multithreading. Cute little concurrency pet tricks
aside, Go concurrent programming actually requires expert level experience.
"You are doing it wrong". Of course. Point.

\- _There is nothing, absolutely nothing_ , that you can do in Go that you can
not do via libraries in Java. Sure, the cute syntactic go func() needs to be
replaced with method calls to the _excellent_ java.util.concurrent constructs,
but the benefits -- high performance, explicit-no-magic-code -- outweigh the
cute factor in this "programmer's" book.

\- On the other hand, there are plenty of things you can do in Java that are
simply _impossible_ to do in Go.

\- Once we factor in the possibility for bytecode engineering, then Java is
_simply in another higher league_ as far as language capabilities are
concerned. (Most people who rag on Java are clearly diletantes Java
programmers.)

If Go actually manages to be as effective as Java for concurrent programming
at some point in the future (when they fix the somewhat broken runtime) then
the Go authors are permitted to crow about it. Until that day, go
fix_the_runtime() and defer bs().

One thing that programming in Go has made me realize is just how awesomely
Sun/Gosling, et al. hit that "practical programming" sweet spot. No wonder the
modern enterprise runs on Java and JVM.

It just works. (But it is "boring" because it's not bling anymore. Oh well,
kids will be kids.)

~~~
agentS
> Go codebases by non experts are peppered with magical incantation (sleeps,
> etc.) to avoid the dreaded "all goroutines are sleep".

I'm confused. This is indicative of a deadlock, where no goroutine can make
progress. Sleeps would mask the symptoms, yes, but would never actually solve
a deadlock, the program would just do nothing for a longer period of time.
What Go codebase(s) are you referring to?

> A concurrent Go program will likely behave differently given 2 bits (just 2
> lousy bits) of difference in the object binary. (runtime.GOMAXPROCS(1) vs
> runtime.GOMAXPROCS(2)). Imagine someone touching those 2 bits in a "large
> codebase". It is practically impossible to do the same thing in a large Java
> codebase and fundamentally change the programs runtime behavior. (Happens
> all the time in Go.)

If you are trying to find a low number of bits, you can just use 0. GOMAXPROCS
can be set via an environment variable, the function is just to override that
value.

More to the point, I am convinced that you are wrong. You are saying that in a
Java class file, there are no 2 bits I could change that would impact the
behaviour of a program, and that is plainly false.

> It is very difficult to reason about a Go routine's behavior in a "large
> codebase" without global view and a mental model of the dynamic system e.g.
> which go routine is doing what and who is blocking and who is not.

I guess this could be true if you engineer a system where every goroutine
depends on every other goroutine. But it isn't true for code I've seen. As an
example, the http library in Go has a goroutine that accepts TCP connections,
and a goroutine for every accepted TCP connection. This knowledge is not
necessary to use it, and is not necessary if a different part of your program
is using it, because it is exposed behind an abstraction (http.Handler). To
paraphrase the OP, Go enables simple programming. It doesn't forbid bad
programming.

> There is nothing, absolutely nothing, that you can do in Go that you can not
> do via libraries in Java.

Depending on what you mean by "do", I believe Turing would have something to
say on this matter: <http://en.wikipedia.org/wiki/Turing_completeness>

> On the other hand, there are plenty of things you can do in Java that are
> simply impossible to do in Go.

Depending on what you mean by "do", I either agree with you, or think you are
mistaken. If you mean things that you can syntactically write down, like a
Giraffe is-a Animal, or an Apple is-a Fruit, then yes, that is impossible to
write down in Go. If you mean a problem that can be solved in Java that cannot
be solved in Go, then I think you are mistaken.

> Once we factor in the possibility for bytecode engineering, then Java is
> simply in another higher league as far as language capabilities are
> concerned.

Why is this in another league? You can use assembly from Go, meaning you can
generate code and jump to it if you really want to. Not sure why this would be
considered a special feature of Java, or even why you think Java pioneered
this. Bytecode is just a portable assembly, but its just as portable to build
per-platform assembly emitters (like compilers do).

> Most people who rag on Java are clearly diletantes Java programmers.

Right. That makes sense to me; no one who knows anything about Java would ever
criticize it. Sarcasm aside, this demonstrates a fallacy in reasoning.

> If Go actually manages to be as effective as Java for concurrent programming
> at some point in the future

It isn't more effective now? News to me.

> when they fix the somewhat broken runtime

Sorry, remind me what this is referring to?

> It just works. (But it is "boring" because it's not bling anymore. Oh well,
> kids will be kids.)

This is dangerous thinking. This is the cry that the native programmers raised
when Java was born. Try and keep that in mind.

~~~
rat87
> > when they fix the somewhat broken runtime

> Sorry, remind me what this is referring to?

I think he may be talking about the conservative gc which causes memory to
effectively leak a lot on 32 bit machines.

<http://code.google.com/p/go/issues/detail?id=909>

~~~
xyproto
Perhaps most people use 64 bit on their servers nowadays.

Judging by the rate of releases of minor versions of Go, I bet it will be
fixed in about two months from now. They are certanly aware of the issue.

~~~
OceanSpray
The issue is actually impossible to fix without overhauling the entire
language. It's impossible to garbage collect unboxed objects without being
conservative.

~~~
ralfn
Exactly. But conservative GC sounds like a dumb idea in the first place. Im
not the expert these people designing these languages are, but i can not
understand how memory leaks can ever be acceptable just because the
probability of it seriously affecting you, is low (when on x64). Doesnt that
just imply you can not use these types of languages in any mission critical
context.

I must be wrong though: it seems Google is using it for parts of their
infrastructure, and im assuming those are long running procceses. But what if
the worst case scenario does happen? Are there workarounds? Monitor memory
usage, and just restart? Can we force the runtime to free a certain resource?

What am i missing? How does this not completely destroy anu utility of these
languages? Why do people put conservative gc in languages outside of the
esoteric or academic context?

~~~
agentS
> Doesnt that just imply you can not use these types of languages in any
> mission critical context.

No more so than with C++. There is a relatively high probability of you having
left a memory leak in an average C++ server.

> Monitor memory usage, and just restart?

That would work, and is probably a good idea for all servers anyways. I've
seen apache take upwards of 60 gigs due to some misconfiguration, so
monitoring memory utilization of your programs and alerting or automatically
restarting is a good idea.

> What am i missing? How does this not completely destroy anu utility of these
> languages? Why do people put conservative gc in languages outside of the
> esoteric or academic context?

There isn't really a good reason as far as I can tell. The only advantages are
that its much simpler to implement, particularly when you have C interop. You
can annotate Go objects with types to do precise collection, but as soon as
you pass them to C, a lot of guarantees the Go typesystem makes go out the
window. Other than that, can't think of anything.

------
etrain
I'm pretty stoked on Go. I freaking love C. Love it. It's like they took C and
went to the best disciples of C's creators and said "look - we've got these
problems now nobody envisioned 40 years ago. Can you make C for us again, but
better?" And they said "yes!" and it was good.

We get some nice concurrency primitives, garbage collection, cleaner syntax,
something between structs and objects that fits the right feeling, automatic
bounds checking, cute array syntax, and a big-ass, well defined standard
library. Oh, and this concept of interfaces that is so well executed it's not
even funny.

Except. I feel like they are forcing the fanboy mindset. At one point in this
slide deck, there is the following bullet: "The designs are nothing like
hierarchical, subtype-inherited methods. Much looser, organic, decoupled,
independent."

I didn't see the talk. But that is the most vapid, meaningless description
I've ever seen of a feature of a programming language. Rob might as well have
said, "it's hipster better," which would have conveyed exactly as much
meaning.

So here's my question - and I hope there are real answers - can someone point
me to >3 real, big systems that are built using Go? I'll accept Google
internal systems on faith.

~~~
Jare
> It's like they took C and went to the best disciples of C's creators

I'm confused, didn't they go to the _actual_ C creators? Or am I
misunderstanding something?

~~~
icebraining
Except for Ken Thompson, not really. Neither Dennis Ritchie nor Brian
Kernighan (K&R) were involved in Go, as far as I know.

~~~
_ak
Ken Thompson wasn't actually involved in the development of C. He created B,
though.

------
isbadawi
I was a bit confused at slide 35 where he said that Go's declaration syntax is
"easier to parse -- no symbol table needed" as I don't typically think of a
symbol table being involved in parsing. Here's an interesting comp.compilers
thread from 1998 about parsing C++:
<http://compilers.iecc.com/comparch/article/98-07-199>

~~~
abhayb
Couldn't pass this one up seeing as I should actually be dealing with this for
a class instead of commenting on Hacker News. What it means is that certain
sets of symbols cannot be parsed unambiguously without information generated
during the parse itself (the grammar is not context-free).

The link in the sibling comment has the canonical example:

foo * bar;

can either be parsed a multiplication or a declaration depending on whether
"foo" has been typedefed previously. So you need to keep track of typedefs in
a symbol table to correctly parse things.

The biggest problem with this is that many parser generators (including yacc)
are much harder (if not impossible) to use with context sensitive grammars.

~~~
sytelus
To me it looks like Go is designed to make compiler writer's life easier
rather than programmers. Why is it so important to save on symbol table if it
does make language less intuitive (at least for people with C background)?

We should be moving towards compilers that are capable of dealing with even
more closer to natural semantics, not the other way around.

I'm suspecting similar mindset was at work when making decisions on error
handling which, IMO, is the most appalling part of Go. If you have coded in C
most of your life then it's same ugliness as usual but for others it's a huge
move backward. Again the designers of Go could have implemented exceptions and
let programmers choose what mechanism they prefer. This would be same as in
Java or C# where a programmer can _choose_ to return error values instead of
raising exceptions. But I guess that would be more work for compiler writers.

~~~
dchest
_Why is it so important to save on symbol table if it does make language less
intuitive (at least for people with C background)?_

Because Pascal-style declarations are superior in readability. With type
inference, they also allow less typing ("foo :=" instead of e.g. "auto foo
=").

You are going a learn a completely new language, new idioms, new standard
library, new tools, and you're arguing that switching to a different style of
declarations, a very _very_ minor detail, is "less intuitive"? I'm not sure
how intuition applies there: are you learning a language by trying to compile
what you typed without reading any documentation or what?

 _Again the designers of Go could have implemented exceptions and let
programmers choose what mechanism they prefer._

Because making them optional doesn't work well. If someone uses exceptions and
someone not, combining code from those two people will make you use _both_
exceptions and error returns. It would be even messier than indicating errors
in C (does this function return 0 on error or -1 or what)?

~~~
PommeDeTerre
It's arguable that the Pascal-style declarations are superior in readability.

I've discussed this with colleagues in the past, and those who were raised
with English as their native language, for example, often find C-style
declarations easier to comprehend. They find the adjective (that is, the type)
coming before the noun (the variable name) more natural.

The opposite happens for those whose native language is one where adjectives
follow nouns. They find the Pascal convention easier to comprehend.

~~~
dchest
The existence of this website <http://cdecl.org/> confirms that even English
speakers find it hard to read C-style declarations :-)

Plus, types can be seen as nouns instead of adjectives:

    
    
        int x
        variable x is an integer
        var x int

------
nnq
Thinks like this have an unnerving "smell":

"Dependency hygiene trumps code reuse. Example: The (low-level) net package
has own itoa to avoid dependency on the big formatted I/O package."

...now, if this kind of attitude stays in the core dev land I don't really
care about it. But when I'll consider Go as an alternative for a large
project, I'll start worrying if people adopt the "it's OK to reinvent some
wheels" philosophy when they start building higher level frameworks in Go... I
mean, how hard can it be to split the "big formatted I/O package" into a
"basic formatted I/O" package and an "advanced formatted I/O package" that
requires the first one, and have the "net" package only require "basic
formatted I/O" (or maybe even make "basic formatted I/O" something like part
of the language "built ins" or smth - I don't know Go so I don't know the Go
terms for this)?

~~~
agentS
> I'll start worrying if people adopt the "it's OK to reinvent some wheels"
> philosophy when they start building higher level frameworks in Go...

I certainly don't have this philosophy, and I don't know thats its a thing
amongst Go programmers. I think its just a standard library thing.

> I mean, how hard can it be to split the "big formatted I/O package" into a
> "basic formatted I/O" package and an "advanced formatted I/O package"

It would easy, but then you're cluttering your library to make implementing
the std lib easier, rather than making the lives of people using the std lib
easier.

> or maybe even make "basic formatted I/O" something like part of the language
> "built ins"

Things that are in the language built-ins would need to go in the spec, and
would need to be implemented by two separate compiler suites. The authors seem
to be doing their best to keep the core as small as possible. Having libraries
written in Go is cleaner, reusable across compilers, and give newcomers a
place to read idiomatic Go.

~~~
nnq
> It would easy, but then you're cluttering your library to make implementing
> the std lib easier

yeah, but the "advanced formatted I/O" package can include all the function
from the "basic" one (i.e. act as if it contains all the functions and structs
from both of them) and be the only package 90% of regular language users know
about, and if happened to need to write some low level code that only needed
the "basic/low-level formatted I/O" I would just import that ...it just seems
100x more "sane" to do it this way

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

------
lnanek2
I never liked Go, but I admit I like it a lot more if it means I don't have to
deal with Maven and other dependency systems as much like the slides say. I've
been doing Android since it came out, but before that I was J2EE, and it could
be hell if Hibernate needed a different version of a dep than something else
in your code stack, for example. Handling JARs by hand stopped working, and
the countless XMLs files listing deps for all parts of the system and library
started getting full of overrides and the like. Eventually Oracle rewrote all
the class loading for their app server which allowed dependencies to have
dependencies which were invisible to apps using them. So something as basic as
class loaders had to be completely reworked to deal with this, and it was
still damn complex and a pain in the ass.

~~~
codewright
>I never liked Go, but I admit I like it a lot more if it means I don't have
to deal with Maven and other dependency systems as much like the slides say.

Hrm, yeah, there are alternatives here. (Not in Java-land...other places.)

> I've been doing Android since it came out, but before that I was J2EE, and
> it could be hell if Hibernate needed a different version of a dep than
> something else in your code stack, for example.

You really should look into Clojure.

~~~
geoka9
Wait, isn't easy access to Java libraries one of the premises of Clojure? In
that case Java's dependency issues still apply?

~~~
codewright
Yeah but then you get to use Leiningen, not Maven.

Leiningen is manna from heaven.

------
ek
I think all of the keynotes at OOPSLA this year were surprisingly engaging.

I've seen a lot of Go talks from various Googlers, and I have to say that this
was the best-motivated, most humble, and most honest of them that I have seen.
Rob knew he was speaking to an extremely PL-oriented audience, and structured
his talk accordingly, and the result was fantastic. Go comes from a very
different standpoint than almost all academic PL work, and in that respect,
for those of us in academia, it's an interesting breath of fresh air and a
reminder of the uniquely fine line between industry and academia in computer
science.

------
ExpiredLink
<http://talks.golang.org/2012/splash.slide#11>

> Pain

> What makes large-scale development hard with C++ or Java (at least):

None of the points apply to Java.

------
lmirosevic
"Go has garbage collection, only. [...] Day 1 design decision."
<http://talks.golang.org/2012/splash.slide#51>

Can someone tell me why GC was the obvious choice as opposed to say automatic
reference counting?

~~~
jlouis
If you squint your eyes enough, automatic reference counting is a garbage
collection method. But if you are going down that road, there are other
garbage collector schemes which often produces way better performance in the
common situations, i.e., copying collection or Mark'n'sweep.

But it is a trade-off. Refcounting collectors need to address pointer cycles.
And they are also quite slow due to all the refcount bookkeeping going on all
the time. But they have the nice property that the lifetime of an object won't
linger around in a zombie state. And there are no point in time where the
system is in a "collecting" state and cannot give service.

That said, many modern, multi-core malloc() routines contain a lot of ideas
from GCs in them. The gap is closing fast.

------
jlgreco
As a warning, there seems to be no mouse-navigation of these slides. You have
to use a keyboard. (or touch, probably)

~~~
nacs
Actually there is but it's actually a bug it seems..

You can scroll side to side to navigate through the slides (swipe left or
right with 2 fingers on Macbook touchpad). However, this seems to only allow a
few slides to load -- the swiping doesn't trigger the 'next slide' javascript
so only a few prerendered slides are usable.

~~~
warmfuzzykitten
There's an interesting bug if you arrow past the end of the slideshow. It
moves a distance not on a slide width boundary, so if you arrow back from
there you're in the middle of the last slide, and so on.

------
wnoise
One of the few nice things about the C include mechanism is that it's pretty
easy (and standard practice) to set up separate implementation and interface
files. If the implementation of something changes, but not the interface, I
don't want to have to recompile all the clients. This is lost in almost all
"modern" languages.

(This is, of course, horribly broken in C++ which likes to inline everything.)

~~~
Evbn
Java has interfaces.

~~~
wnoise
Not the same thing. Think public-vs-private portion of a class.

~~~
pjmlp
The only advantage Go interfaces have over interfaces in other languages, is
that you can make third party code comply to a given interface if you're lucky
enough to have the same set of methods available.

Even then, you might hit the issue that although the interface matches
syntactical, the semantic meaning of the method calls differs.

For the CS folks, Go interfaces are nothing more than structural typing,
available almost any FP language.

The only advantage over Java, C#, D is that you are not required to state
explicitly which interfaces a given type implements.

However this forces you to use tools to discover which interfaces a given type
implements.

------
pswenson
Didn't we try error codes back in the day? I think exceptions are brilliant.
They let you write your error code in one place (at the top of the stack),
instead of planning for every contingency at every level.

Once I discovered exceptions back in the 90s, life got a lot easier.

Of course Java ruined exceptions with the invention of the CheckedException,
maybe this tainted the Go designers' thinking?

~~~
ConstantineXVI
As someone that grew up with exceptions, I like the idea of errors being
recoverable by default. If it's not fatal, your catch block is going to
swallow the exception anyway. And if your error is, panic().

(This could be Java experience scarring my then-young mind)

~~~
pswenson
Most exceptions aren't recoverable. They are _usually_ a result of bugs or
system problems. This means 1) the bug needs to be fixed. 2) the system needs
to be fixed (start up a DB service, clean disk-space, add memory, etc).

This is where java went wrong, java checked exceptions treats everything as
recoverable when recovery is unlikely.

I mean, someone tries to login to a web site and the DB is down. What do you
do? Or there is a bug that throws a null pointer exception. How do you recover
from that?

I think the error code approach has the same effect as CheckedExceptions.
People will tend to code to ignore the problems and not report them.
Exceptions are great in that they bubble up to the top of the stack, so they
are easy to report/alert on.

------
lukehutch
Favorite quote: "While that build runs, we have time to think."

~~~
btilly
That reminds me of a story that I read ages ago. It happened in the 1980s.

This group of programmers had taken to exercising while waiting for compiles.
They were all buff. Then Turbo Pascal came out and they all turned back into
couch potatoes. :-)

~~~
tommorris
Exercise. That's what I'm supposed to be doing while Maven downloads the
Internet.

------
simonsarris
Sorry to veer off topic, but why is the golang site so _ugly?_

I clicked on the link in the second slide: <http://golang.org>

compare with:

<http://www.ruby-lang.org/en>

<http://git-scm.com/>

<http://www.haskell.org/haskellwiki/Haskell>

Even Dart looks great: <http://dartlang.org/>

I feel a little guilty being negative about this, but presentation does
matter, and Google ought to be able to afford it.

~~~
beatgammit
I think it's nice. It's super functional and easy to find information. It may
not be pretty, but I know exactly where to go to find what I want.

I like that the urls are consistent. To find package documentation, I go to
golang.org/pkg/<name of import>. For example, for http docs, I go to
golang.org/pkg/net/http.

For most languages, I resort to a Google search to find package docs. This is
true for python, c++, and even Java. I rarely have to google search something
in Go.

I think the site very much fits in with their goal of simple and orthogonal. I
actually wish more language documentation followed suit and made it easier for
programmers to search for docs.

Sure, everyone wants a pretty site, but it's not like they need to advertise
anything. It gets the job done very efficiently.

~~~
dualogy
Regarding docs, what's also extremely neat is, when you're offline, just run
"go doc" and it starts an HTTP server on your local machine to serve the exact
same fine documentation experience. So thoughtful, one of many small details
just part of the overall package, when you need them you find them easily and
are delighted.

------
ybaumes
Does someone knows wath is the reference to Tom Cargill and "PI" in the 16th
slides please? I did not find anything on Google.

------
tomdeakin
I spent a year working on a project in Go, so got pretty used to the language.
One thing I did wonder though was how would it fare on very large systems; how
could Go hook up to work like MPI across clusters of computers?

------
ddon
slide show didn't work for me in FireFox... haven't tried it in Chrome :)

Update: was trying to use a mouse to switch between slides, but later tried,
and figured out that it only works with keyboard :)

------
pdog
I can't be the only one for whom this presentation is completely broken on the
iPad (scrolling to fast and skipping multiple slides).

------
smegel
> It can be better to copy a little code than to pull in a big library for one
> function.

I just don't get this. If you statically link in small functions from a big
library, you only get the little bit you need anyway. Are they saying you
avoid compiling the "big library" over and over? But if it is already
compiled, that should not be necessary. And the chances are you are going to
be importing lots of "little code" from the "big library" anyway. Unless they
are saying the implementation of net's itoa is somehow simplified and not a
just a straight code copy...otherwise I don't understand this approach.

~~~
beagle3
> And the chances are you are going to be importing lots of "little code" from
> the "big library" anyway.

That "big library" is often supported by someone else. One day, a year down
the line, you realize startup time for you executables went from 0.01s to 2s
because Big Library's initialization code now scans all subdirectories for
some caching optimization, and stuff like that - stuff that's a win for
general users of biglib, but not for you.

> I just don't get this

This is not about theory, it's about practical experience.

You'll notice that successful C/C++ libraries tend to include everything
that's small enough and that they need to function - because dependencies byte
you later on. e.g. libav/ffmpeg has its own copy of md5, libtcc has its own
slab allocator, gsl has its own everything, everything ships with a copy of
libz in case the system libz is borked.

The Go library just starts applying this principle a little earlier - inside
the standard library. I suspect that's because they envision a python-style
batteries-included extensive standard library, which has no benevolent
dictator to put order in it.

------
drivebyacct2
I miss uriel to respond to some of the really inexplicable posts on this
thread. :(

------
Evbn
I don't get the interface stuff. If you had a method on an interface, you have
to add it to all implementors, or clients won't compile. How is that different
from Java? Java just adds the implements declaration, so Eclispse can help you
find those implementations, instead of making you pore over compiler error
listings.

~~~
isbadawi
In Java, you can run into situations where two classes share a method, but
because they don't implement a common interface, for instance because they're
part of two different libraries, you can't e.g. write a method that accepts
instances of either. You can't straightforwardly take advantage of
polymorphism.

In Go this is never an issue; you can declare an interface that captures the
methods you're interested in, and the existing code automatically implements
it. It's kind of like duck typing in python (e.g. this function will work on
any object that has a method <x>), except it's statically typed.

~~~
pjmlp
Just because the method complies to the interface does not mean it does what
you would expect from it.

static fulfilment != semantic fulfilment.

~~~
msbarnett
You could equally say that just because a class declares that it "implements"
an interface, it doesn't mean it does what you would expect from it.

In practice, there is no language that can save you from people with malicious
intent to confuse you.

In practice, this is rarely an issue.

~~~
pjmlp
There is a big difference.

When a developer makes a class implement an interface s/he signing a contract
thus validating assumptions.

When a type in Go matches an interface, it happens by chance.

~~~
msbarnett
Utter nonsense. Either a function/method is semantically compatible with the
expectations of its caller, or it is not.

Whether or not the function/method's author typed the words "implements Foo"
has absolutely no impact on this.

