One Hundred and Fifty-Three

Post number two in the ongoing “I just learnt this programming language, sit still while I rave about it” series.

So yeah. Go really is as awesome as I was hoping, but sadly not one microstinson more.

The Good

Google’s right: it feels like an interpreted language. Stuff like slices and first-class functions give the impression that you’re not shouting down the phone to a compiler that has its own ideas of how to do stuff, you’re nicely asking an interpreter, and it comes back with “why yes, that’s exactly what I had in mind”. The lightweight type system never obtrudes. It lets you know where you go wrong, helps define your program’s structure, then gets the fuck out of the way. And the interfaces are a breath of fresh air. I never want to have to type implements again. “Yes, Java, I know it implements this interface. I wrote the class and the interface, and look! They both have the same methods!”

The Bad

So Go’s a compiled, statically type language that thinks it’s dynamic and interpreted. So it thinks it has duck typing and duck punching. While the receiver syntax for methods is commendable, it only lets you enhance your own types. Now, when punching ducks, I’d like to be able to punch any duck. Hell, sometimes I want to punch geese or swans or… the point is, being able to augment built-in types is a huge boon, cutting down in utility classes and functions. And while Go lets you use a local type alias, you then need to wrap your types to make sure they get the methods.

The Ugly

Good God, is reflection awful. Things I’ve taken for granted in Javascript these past years take five times as much code, then don’t actually give you the objects you were looking for. Instead, you just get a reflection wrapper around them, so you have to use five times as much code calling methods. Except the arguments you pass have to be reflection wrappers around the values. I feel like I should be swearing some more to convey the sheer frustration it gives me. Tits. Arse. Seriously, just compare:

var prop = "foo",
    meth = "bar";
thing[prop][meth](1,"hello",false);

with:

prop := "foo"
meth := "bar"
reflect.ValueOf(thing).FieldByName(prop).MethodByName(meth).Call([]reflect.Value{1,"hello",false});

Preposterous. If included at all, reflection should be baked into the language. At the very least, a subscript notation for struct properties and methods could be implemented. But then, of course, you don’t know what properties or methods are being accessed, so you don’t know they’re types, so you don’t know what to call them with or what properties they have and your back to square one and this is why I like dynamic languages, goddamnit.