Google Go

I just read through the language spec and memory model for Go, Google's new language (thank you for the link Scott.) There are a lot of things l like about the language, such as its approach to concurrency, heavy use of type inference (which we also see in C# and Java 7), ruby-like array and map manipulation syntax, etc., but I'm not entirely sold on the type system. Go has no concept of inheritance, which they cite as a good thing because Go types are "light". From the Go docs:

Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods. Besides reducing the bookkeeping, this approach has real advantages. Types can satisfy many interfaces at once, without the complexities of traditional multiple inheritance. Interfaces can be very lightweight—having one or even zero methods in an interface can express useful concepts. Interfaces can be added after the fact if a new idea comes along or for testing—without annotating the original types. Because there are no explicit relationships between types and interfaces, there is no type hierarchy to manage or discuss.

Um... OK, so you have this sort of loosey-goosey approach to interfaces (if I have the methods, I satisfy the interface), but what about super class constructors and concrete (non-abstract) methods? I'm having trouble imagining libraries such as UI toolkits (WPF, Flex, Swing, etc.), which effectively make heavy use of relatively deep inheritance trees, being written in as elegant a manner in Go. Those super classes are doing a lot of work, and the type hierarchies provide a nice taxonomy for the API. Perhaps Go is advocating the use of a different paradigm to accomplish the same thing, but it doesn't seem to be readily evident from the docs.

Two areas where I think they are definitely making a mistake:
- The lack of exceptions. I guess they don't like the whole concept of signals.
- The lack of generics. The docs say they may get around to generics, but that it isn't a priority.

Thoughts?

Update 5/13/11: Go has introduced signal constructs called Defer, Panic and Recover that provide a form of exception handling. I haven't yet decided if I like them better than exception handling in Java / C#.

Ikayzo - Design • Build • Localize | Web • Desktop • Mobile