Even Google can't "think different" when it comes to language design - the straightjacket of C language syntax conformance has been fitted around their new Go language. I took a short walk around the FAQs and language description, and came away somewhat non-plussed:

• C style syntax - I suppose this continues the "it looks like what I know already" thing, but it also makes it harder to break from the past
• Which leads to: Pointers, but no pointer arithmetic. That just makes no sense to me. Either you don't need pointers (because, as with Smalltalk, everything could be considered a pointer), or you really want the power. This seems like a halfway house that will make no one happy
• Go has Casts, which is, IMHO, a huge mistake. A type system that includes Casts is a type system that the designers know has problems. I feel like Obi-Wan - "Just use the force, Google"
• No function overloading and no user defined types. Back to one of my favorite issues - the old "designer is a god who knows all possible uses" error. This is how Java ended up with helper classes all over the place; seems Go will get to the same bad place
• Instead of "while", you can add a condition to a "for" loop. To quote Google's page: "Omitting the condition entirely is an endless loop.". There's a whole class of needless bugs introduced right there, guys. Brilliant.

Constants look interesting - they are untyped, but they gain an implicit type based on context. I love code that makes me guess what'll happen based on the surroundings. This mixture of static typing and dynamic typing is kind of a worst of all possible worlds thing; IMHO, you need to go in one direction or the other. Obviously, I prefer dynamic typing, but this half in/half out thing is just asking for trouble.

I will say that providing interfaces instead of the bizarre mix of things in C++ was a good idea. Anytime you can pitch N concepts and retain just one, you've made life easier for people.

The Goroutine idea is interesting, but they've elided over an interesting issue - one that Smalltalk (lightweight) threads have, by the way, although having them run as native OS threads gives you even less control. To wit:

All goroutines in a single program share the same address space. Internally, goroutines act like coroutines that are multiplexed among multiple operating system threads. You do not have to worry about these details.

Except that you do need to worry about the details - at least the relevant ones. It's just as easy to use #fork in Smalltalk, but that doesn't relieve you of the need to worry about shared state issues. All Goroutines run in the same address space - unlike Erlang's "share nothing" concept, this is "share everything". Making it easy to invoke an OS thread is not the hard problem; the hard problem is state. Channels (akin to class SharedQueue in Smalltalk) can be used to communicate between Goroutines, but that just doesn't help. Having them all in the same address space means that your state issue is still there, waiting to explode.

So what do I think, overall? It could be considered a better Java, but not by a lot. Creating new threads in Java is easy enough. It's harder than Python, because it adds a static type system (with the wonderfully ambiguous Constant thing). They claim it compiles fast, which would be a benefit - but I'd like to see some real world examples of that. Ultimately, I just don't think that Goroutines buy you much. If you go to their memory model page, you'll note that there's syntax for locks and synchronization - and that's because you still have a shared state model going on. I can see this being a simpler language than Java or C++, but I don't see it being that useful for most users of Smalltalk, Ruby, Python (et. al.). The complexity level seems lower than C++ or Java, but higher than the dynamic camp - and it doesn't seem to be bringing enough to the party to make dynamic language users switch. The big win over C++ (and, to a lesser extent, Java), is package (dependency) management. Looks like they've done a good job at simplifying that.

That's my 4 cents, anyway - what do you think?

Technorati Tags: Go, language design