12 ms·

A thorough evaluation of Go from a Google Employee

99 points by smanek 17y ago

wglb 17y ago
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 17y ago
  Next up, a thorough evaluation of Visual Basic from a Microsoft employee. Doesn't quite have the same ring to it, does it?
  - mbreese 17y ago
    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.
btilly 17y ago
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 http://www.eros-os.org/essays/capintro.html provides a good introduction.
- jerf 17y ago
  "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.1 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).
  - uriel 17y ago
    > 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 17y ago
      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.
UncleOxidant 17y ago
Oh, man, that new pointer syntax is going to trip up a lot of C/C++ programmers...
statictype 17y ago
> 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.
scott_s 17y ago
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.
stcredzero 17y ago
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!
elblanco 17y ago
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 17y ago
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.
SeanLuke 17y ago
So does it have closures?
- btilly 17y ago
  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 http://golang.org/doc/go_spec.html#Function_literals for confirmation and http://groups.google.com/group/golang-nuts/browse_thread/thread/74a37a9923cdf327 http://groups.google.com/group/golang-nuts/browse_thread/thr... for more details.
  - andreyf 17y ago
    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
    - scott_s 17y ago
      That might be possible, but that seems to go against the design goal of making a systems programming language that can replace C.
    - mbreese 17y ago
      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.
    - btilly 17y ago
      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.
jacquesm 17y ago
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 ?
- mtrichardson 17y ago
  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.
- andreyf 17y ago
  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/default?user=frankmccabe&templatefn=FileSharing1.html&xmlfn=TKDocument.1.xml&sitefn=RootSite.xml&aff=consumer&cty=US&lang=en http://homepage.mac.com/WebObjects/FileSharing.woa/wa/defaul... 2. http://en.wikipedia.org/wiki/Ken_Thompson http://en.wikipedia.org/wiki/Ken_Thompson
  - jacquesm 17y ago
    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 ?
uriel 17y ago
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).

99 points by smanek 17y ago

wglb 17y ago

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 17y ago
Next up, a thorough evaluation of Visual Basic from a Microsoft employee. Doesn't quite have the same ring to it, does it?
- mbreese 17y ago
  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.

btilly 17y ago

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 http://www.eros-os.org/essays/capintro.html provides a good introduction.

jerf 17y ago
"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.1 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).
- uriel 17y ago
  > 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 17y ago
    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.

UncleOxidant 17y ago

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

statictype 17y ago

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

scott_s 17y ago

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.

stcredzero 17y ago

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!

elblanco 17y ago

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 17y ago

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.

SeanLuke 17y ago

So does it have closures?

btilly 17y ago
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 http://golang.org/doc/go_spec.html#Function_literals for confirmation and http://groups.google.com/group/golang-nuts/browse_thread/thread/74a37a9923cdf327 http://groups.google.com/group/golang-nuts/browse_thread/thr... for more details.
- andreyf 17y ago
  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
  - scott_s 17y ago
    That might be possible, but that seems to go against the design goal of making a systems programming language that can replace C.
  - mbreese 17y ago
    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.
  - btilly 17y ago
    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.

jacquesm 17y ago

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 ?

mtrichardson 17y ago
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.
andreyf 17y ago
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/default?user=frankmccabe&templatefn=FileSharing1.html&xmlfn=TKDocument.1.xml&sitefn=RootSite.xml&aff=consumer&cty=US&lang=en http://homepage.mac.com/WebObjects/FileSharing.woa/wa/defaul... 2. http://en.wikipedia.org/wiki/Ken_Thompson http://en.wikipedia.org/wiki/Ken_Thompson
- jacquesm 17y ago
  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 ?

uriel 17y ago

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