

A thorough evaluation of Go from a Google Employee - smanek
http://scienceblogs.com/goodmath/2009/11/googles_new_language_go.php

======
btilly
I'm interested in the independent opinions. I hope to see more of them going
forward.

Here is my relatively uninformed opinion based on having read through their
examples and some of the recent discussion.

Having looked at the language a little, I think I understand why they don't
have exceptions yet (if ever). The problem is that they envision using this to
write servers, and the servers will essentially use a microkernel design with
message passing through channels. But when one of your little miniservers goes
down, who is it supposed to report the error to and how will that be dealt
with? If there is no good answer, then what sense does it make to let a
miniserver go down without warning?

To be concrete, take this example from the documentation:

    
    
      func startServer(op binOp) (service chan *request, quit chan bool) {
          service = make(chan *request);
          quit = make(chan bool);
          go server(op, service, quit);
          return service, quit;
      }
    

If an exception is thrown within the server function, who catches it? What can
startServer do? Someone who talked to chan? The last process who tried to talk
to chan? Everyone who tries to talk to chan? Do we shut down the whole
program? Concurrency gives you tangled flow of controls, and you don't have a
simple stack where it is clear who has responsibility for a given error. In
some ways it really _does_ make sense for the server to pass back an error
object somewhere and let someone else figure out what to do about it.

Moving on, I think a better mental model for "interface" is "implicitly
matched mixin". Like a Ruby mixin and unlike a Java interface, once you've
matched the set of methods in the interface you can now call the methods that
are appropriate for that interface. That's very powerful, and potentially very
dangerous. When you write a larger system I could definitely see method name
collisions becoming a big deal.

Moving on, the lack of generics is huge, and I hope they solve it. They have
first class functions and closures, but when asked on the mailing list whether
they support standard functional goodness like map and reduce, the response
was that the type system made that really hard. When I think about it, I can
understand why they are fighting the type system. But if they can add generics
then they can solve that problem. The challenge is doing it efficiently.

And my final thought is that anyone thinking of building a real server out of
this should read up on capability systems before figuring out their
security/permissions model. I say this because having a channel to a service
IS a capability, but most programmers don't realize how powerful that
organizational concept can be. If you think that you're among them,
<http://www.eros-os.org/essays/capintro.html> provides a good introduction.

~~~
jerf
"But when one of your little miniservers goes down, who is it supposed to
report the error to and how will that be dealt with? If there is no good
answer, then what sense does it make to let a miniserver go down without
warning?"

Answer:
[http://www.erlang.org/doc/design_principles/des_princ.html#1...](http://www.erlang.org/doc/design_principles/des_princ.html#1.1)
. You send the error to the supervisor.

Go strikes me as less C++ meets Python than C meets Erlang, but Go has the C
side covered better than the Erlang side so far. If Go "steals" the OTP
framework, and especially if channels grow the ability to span across
different nodes, Google will definitely have something interesting (to me).

~~~
uriel
> if channels grow the ability to span across different nodes

This is being considered, rob said he has been thinking a lot about it, but
obviously they want to get something as important _right_.

~~~
jerf
Absolutely, by all means, take the time to get it right.

I don't know if I'm saying something blindingly obvious or not, but it still
should be said just in case: The team really needs someone who has not just
glanced at Erlang tutorials, but actually used it for significant work. Not
necessarily "hired", but certainly in the loop. The Erlang community could
tell you a lot about what works, and give you a few things that don't work in
Erlang well either.

OTP is killer for reliable server apps, but it's really hard to understand the
full implications until you've used it yourself for a while. Implementing
cheap threads is great, but there's a couple more primitives to grab that make
it truly powerful.

I am advocating this because as much as I like Erlang, I'd really love to see
another language steal its thunder. The syntax and performance are dubious
(not terrible, but not stellar). But while I've seen other languages implement
bits and pieces of the whole, I'm yet to see another community grok the
totality of the Erlang platform and correctly port it into their language,
often because they're trying to graft something into their language that it
just can't support. Go is probably not in that position, and is my best hope
for this sort of thing.

------
wglb
This is a good review of the language from someone who has had a chance to
work with it, and is inside Google. He shows some quite nice examples of its
use, and reports that it is exceedingly fast to compile and generates good
code.

(This is the _Good Math, Bad Math_ blog)

~~~
gaius
Next up, a thorough evaluation of Visual Basic from a Microsoft employee.

Doesn't quite have the same ring to it, does it?

~~~
mbreese
But, how much work does Microsoft really do with Visual Basic? Given the
press, I have a feeling that Google might want to start actually using this
for production work.

------
scott_s
Something that strikes me about the language is that it was clearly designed
by systems programmers as a replacement for C - but not a replacement for C++.
The ability to return and concisely accept multiple values from a function
simplifies procedural error checking considerably - exactly the kind of error
checking that is all over systems code.

------
statictype
> Interface types are similar to interface types in languages like Java, with
> one huge exception: you don't need to declare what interface types you
> implement!

Nice. This seems to add the benefits of duck-typing, but with type checking.

------
stcredzero
This is one of the more thoughtful evaluations I've seen. All too often, a
language evaluator mistakes their misunderstanding of the design for a design
flaw. Evaluating a new language is often the tricky mental task of
understanding a different way of thinking. This reviewer gets it!

------
SeanLuke
So does it have closures?

~~~
btilly
Yes it does. It has full first class functions and closures. However the lack
of generics means that you can't write a general-purpose map, filter, reduce,
etc. You'll need to keep writing almost identical pieces of code.

See <http://golang.org/doc/go_spec.html#Function_literals> for confirmation
and [http://groups.google.com/group/golang-
nuts/browse_thread/thr...](http://groups.google.com/group/golang-
nuts/browse_thread/thread/74a37a9923cdf327) for more details.

~~~
andreyf
_However the lack of generics means that you can't write a general-purpose
map, filter, reduce, etc._

I'm not so sure, why not just define them "dynamically"? From the article:
_it's defined as an empty interface, and everything implements the empty
interface_

~~~
btilly
Well if you follow the second link you will find Adam Langley (one of the
initial developers of Go) saying that the type system precludes a generic map,
grep, etc.

You point out that everything implements the empty interface, but knowing that
something implements the empty interface isn't very useful. A map, grep, etc
needs to be passed a function and a bunch of data, then needs to apply the
function to each piece of data. But the type system can't let you pass a piece
of data to the function unless it knows the types are compatible. So if your
function takes ints and adds them, then you really need to know that all of
your pieces of data are ints. To use functions that accept data of other
types, you will need a different version of grep for every type of function
you accept.

This is exactly the problem that generics tries to solve.

------
elblanco
MarkCC has also written some wonderful poignant work on bullying and how it
affected his life. One of the few blog posts that's really ever moved me.

------
garnet7
I've seen a lot of good analysis of Go, and I hope its creators carefully
consider it and work to make Go (if they keep the name) even better.

------
UncleOxidant
Oh, man, that new pointer syntax is going to trip up a lot of C/C++
programmers...

------
uriel
It is a pity that he doesn't say anything about the awesome CSP-based
concurrency system, which is one of the greatest features of the language.

That aside, it is a very good read (although I think his complaints are a bit
silly, iota might look a bit strange, but works really well, and it is very
simple, anyone can understand how it works in 30 seconds).

------
jacquesm
Articles that label this language 'go' instead of 'i9' or 'issue9' should be
ignored.

Stand up for the little guy and help a bit, with every article that cements
'go' as the new 'go!' there is more damage.

Already you have to look real hard in google to find anything on the 'old' go.
It really isn't fair.

When you're a giant you should tread carefully, lest you flatten someone by
accident.

EDIT: hey downmodders, if you disagree, let me know why.

What would you think if google decided to call their project 37signals or
something like that next week ?

Would you stand by 37signals or would you tell them that on that scale their
efforts amounted to nothing anyway so they should man up and change their name
?

What rationale do you have for giving google a free pass on this ?

~~~
ubernostrum
I have a couple issues with what you're saying.

First, there's a long history of name appropriation about which I'm quite
certain you've never raised any concerns. For example: this site's domain
name, which represents the appropriation of an important bit of CS terminology
by a for-profit concern which isn't in any way related to that bit of
terminology. Where is your outrage toward PG?

And I'm glad you chose 37Signals as an example further on in your post,
because they recently launched a search-oriented (helping designers and
clients find each other) service named "Haystack". A friend of mine was
already maintaining a somewhat-popular (in its niche) search framework for
Python web apps called... Haystack. Guess how many people are standing up and
denouncing 37Signals as the Big Bad Evil Destroyer? You didn't, so far as I'm
aware.

So it seems somewhat hypocritical, or at the very least arbitrary, to single
out Google for the treatment you're advocating while overlooking numerous
other examples of the same thing happening.

And this leads into my second concern: I don't really see how someone can
stake a permanent claim to a name in a field based on not much more than a
niche/hobby project. If "Go!" had been more heavily marketed or more widely
disseminated (or even maintained; it seems to have basically died as a
project), I'd be more inclined to sympathy, but the simple fact is that it
wasn't: until the past couple of days, it had spent its entire existence
shrouded in obscurity, and to my mind that's nowhere near enough to begin
dictating the use of the name to anyone.

~~~
jacquesm
Y combinator was as far as I know not in use for the domain of 'start-up
booster / mentors / incubators'

And I wasn't aware of the 37signals name clash with respect to 'haystack', and
I really wonder how you can expect me to be supportive of things that I am not
even aware of.

But, now that you have raised my awareness to the issue, if the clash is for
the same problem domain, then yes, I think that 37signals should change their
name.

