(This is the Good Math, Bad Math blog)

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

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

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.

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

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.

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

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.

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;
  }

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.

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

This is being considered, rob said he has been thinking a lot about it, but obviously they want to get something as important 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.

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

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.

Regardless, even explicit type variables would be very useful.

Go does not have exceptions for precisely this reason.

Or "named structural types".

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

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 ?

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.

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.

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

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 ?

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.

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

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.

That being said, definitely an interesting read, thanks.

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.