I think many people were hoping for it but Go fell fatally short in 2 key areas IMO:
1 - Error handling - Go doesn't have any powerful mechanism for error handling. The code I have seen is rather inconsistent and it doesn't solve the main problem from C of forcing people to handle errors.
2 - Polymorphism - They left any kind of generics out. I think this could go a long ways for (1) too, just look at Either or Maybe type in Haskell. Combine this with some pattern matching and you have a really powerful way to enforce error handling and have polymorphic data structures and functions. IMO this is the biggest failing of Go.
I think the failure to provide those two things also makes Go a future mess. Adding them later either breaks a lot of outstanding code or it means you have to versions of Go, the original and new which is a mess.
Adding them later either breaks a lot of outstanding code or it means you have to versions of Go, the original and new which is a mess.
Actually, the creators of Go are still not afraid of breaking things. For example, recent release (2011-02-01.1¹) changed the syntax of non-blocking channel operations, and it broke code.
That is good to see. But I would argue that the change described here is a rather small change while the 2 missing features I described have a larger effect on how you design your application.
Well, adding generics shouldn't break working code.. it's an additive change.
It says something that for the built-in collection types, Slice and Map, they had to hack around their own API and implement this-case-only ad hoc generics. Slice and Map should be fully implementable within the language.
Why should Slice be fully implementable within the language?
C++ is another systems language that decided that everything should be able to be done in libraries, and we've all seen the complexity that results.
Well, I'll back off slightly from the assertion "fully implementable" because you have the f = s[i] syntax which wouldn't be fully implementable unless you allow the user to define [], which I agree is crazytown.
However, the make() functions for slice and map are the only functions in the language that allow you to pass in a type and get that type back as a return function. Why can't users have that functionality? Generics seem to be the easiest way to get it.
I think I agree, but I'm not good enough at language design to be sure. :) In the current language, all uses of type literals need to be known at compile time; if I could pass a variable containing a type to "make" or use it to instantiate a map, the language needs generics to deal with that, and all of the complications that come with it.
The current idiom seems to be (if I wanted my own "make"):
myslice := mymake((MyType)(nil), 10).([]MyType)
which is much uglier than the built-in way. However, I'm kinda okay with reflection-laden runtime tomfoolery looking a bit messy, mostly because I rarely use it, and when I do I like it to stand out and be obvious what is going on.
To date, I have seen no language except Qi that (1) supports sum types, and (2) isn't a statically typed functional language.
Anyway, it's not like a wannabe OO language would adopt Algebraic Data Types. "Those are for these ivory tower languages that no one use in the real world", one might say.
