Hacker News new | comments | show | ask | jobs | submit login
A thorough evaluation of Go from a Google Employee (scienceblogs.com)
99 points by smanek on Nov 11, 2009 | hide | past | web | favorite | 45 comments



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)


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

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


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.


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?


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... for more details.


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


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.


Or have an interface "mappable" or "filterable", and then have everything include those methods...

It's possible, but it does add a bit of extra complexity.


That might be possible, but that seems to go against the design goal of making a systems programming language that can replace C.


How do closures work in a language that has pass-by-value semantics? Does it copy all the closed-over data into the closure itself? Is the closure itself always heap-allocated and pass-by-reference, or is it pass-by-value?


I'm not sure why you think there is a problem to be solved.

When you execute some code you bind an environment to that code. (This binding step is necessary if you want recursion to work.) In the case of a closure you just leave the environment bound to the function that returns. It is irrelevant how data got into the environment - as long as it is there and remains bound to that scope, the closure will work.

To be able to do this the environment needs to exist on the heap. However when you add the concurrency semantics that Go has, allocating things on the heap makes a ton of sense in general.


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.


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.


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


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


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.


But if they can add generics then they can solve that problem.

They don't need explicit 'generics' like in Java 1.5 -- they need to go back to the source, and adopt Haskell's type inference and parametric polymorphism. They already have basic type deduction, but it's only at the syntax level.

They should really add GADTs to the type system, with pattern-matching over them, but that doesn't fit at all with Protocol Buffers, so it might never make it.

Their 'case' statement is pattern matching already -- it doesn't do passthrough by default, it isn't a jump-table (not restricted to constants), and already has a special form for matching over types. They'd just have to cross the streams...


Adding a Hindley-Milner-like type-inference to a language that has subtype polymorphism and method overloading is really not a good idea (or possible for that matter).

let plus x y = x + y

let sum = plus 1 2

This is Ocaml, but let's assume it has type-classes. Method "plus" would be a generic method with a type like ...

(Num 'a) -> (Num 'a) -> (Num 'a)

The actual return type (int) is detected when the actual call is made. But that's assuming you know the actual types of the parameters at compile-time. And that's not the case in OOP languages ... by definition they have (at least) single-dispatch.

That's why languages like Ocaml don't allow this. Full type-inference and languages like Java / C# don't mix.


Go doesn't have method overloading, and it doesn't have polymorphism in the traditional sense either. (Not sure what effect Go's Interface inference has on H-M.)


I think it's ok. I would think it's like type classes, which work pretty well for Haskell. And Go doesn't need full-fledged type inference. I bet they could work something out that's simpler and more explicit.

Regardless, even explicit type variables would be very useful.


If an exception is thrown within the server function, who catches it?

Go does not have exceptions for precisely this reason.


> I think a better mental model for "interface" is "implicitly matched mixin".

Or "named structural types".


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 ?


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.


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.


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

There is absolutely no chance that Go! will ever amount to anything aside from a bit of research. It's hosted on a homepage.mac.com account [1], and hasn't been updated in over two years. Google's Go, on the other hand, is designed by ken [2], at what's arguably the top industrial research lab in the country. It's designed to replace C++.

1. http://homepage.mac.com/WebObjects/FileSharing.woa/wa/defaul...

2. http://en.wikipedia.org/wiki/Ken_Thompson


So, because google is big they get to do as they please ?

The 'bit of research' is roughly 30 man years. There is a book in print about it. Until yesterday you could actually find something about it on the internet.

Whether or not it amounts to something in your eyes does not give google the right to just stomp all over it and appropriate that name.

Might does not make right.

How big something is depends on your position and perspective.

If 'being updated in the last two years' is a criterion why didn't they re-use algol ?

There is this thing called corporate responsibility and google is displaying very little of it in this particular case.

It's interesting how 'who designed it' and 'where it was designed' seems to be enough to give them a free pass to do this in your eyes.

What do you expect me to do with the link to Ken Thompson ? Are you introducing me to him ? Do you think it matters that he's involved in this with respect to the name of the project, not the quality of the language or the concepts in it ?


"So, because google is big they get to do as they please ?"

Consider a different phrasing: if I start a project with a particular name, work on it for a bit and then abandon it for a few years, do I have a right to demand -- forever -- that no-one else use the same or a similar name?

It's instructive to note that in many countries, trademark laws include the concept of "abandonment", whereby a name or mark can lapse through disuse.


So, you are effectively arguing that since the namespace is finite that google had no option but to pick a name that was already in recent use ?

How would you feel if they took the name 'arc' for this project ? After all, arc is a one guy 'hobby project', and it's state of maintenance seems to be such that it will not be ever in wide distribution, that makes it fair game right ?

As far as I'm concerned, any language that has an entry in 99 bottles is in existance, whether maintained or not doesn't enter in to it, it takes 30 seconds to verify if a name is 'taken'.

http://www.99-bottles-of-beer.net/language-go!-289.html


"So, you are effectively arguing that since the namespace is finite that google had no option but to pick a name that was already in recent use ?"

No, that's you making things up and trying to pretend that I said them.

And, again, the fact that "Go!" looks rather strongly like abandonware makes me wary of granting its author the right to demand no-one use the same or a similar name.


This is silly, and off-topic, and you're right that the concepts in a language are what matter. Incidentally, that's also what this article is about, so let's focus on that.


this comment now makes no sense because the parent got edited.

Both are programming languages, 5 minutes of work on googles part would have resolved the clash.

Either they've been careless (doing your homework before you stake a claim on a name is important, see the 'gmail' fail in Germany, which they rightly lost, and yes, that was a trademark dispute, and in spite of being clearly wrong from the get-go google decided to push on and on in a clear attempt to crush the other party with litigation when everybody could see they were just plain wrong).

Or they've been doing this wilfully, in which case they deserve no respect at all.


I'm seeing the opposite effect. When googling for "go", first I get the Go buses that make up some of my local public transit, then the Go board game, and then the programming language at #9. It might change as the hype builds up, but I don't see it happening now.


If you search for 'go programming language' you'll see what I mean.

That overnight boomed in to 35,000,000 mentions, only a very small portion of it refers to the original.


I had no idea what you were talking about until I wikipedia'd it. Some context might have helped your original point.

That being said, definitely an interesting read, thanks.


If the name of your project is important to you, register a trademark (or actively use the name to establish a trademark). Without a trademark you don't "own" the name, and anyone can use the name for a similar product/service/etc...


Even with a trademark you don't 'own' the name, you'll have to go to court for every infringement, which is for almost anybody that does not have a very large business interest in a name an un-affordable option.

Also, given googles actions in the gmail.de case it seems as though they don't really care about trademarks anyway, they'll just keep on pushing.


Get a life.


I'm sorry ?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: