A thorough evaluation of Go from a Google Employee

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.

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)

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.

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

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!

So does it have closures?

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.

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.

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

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

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 ?