Go is boring

Clickbait headline aside, I think Go threw some baby out with the bathwater in the march to simplicity.

An example; try to sort a slice of runes.

The setup needs a little boilerplate, but it's definitely possible. And it can support different sort orders after writing the boilerplate once. For those wanting to test drive it: http://play.golang.org/p/I_Vu34hUoV

Since it seems down, here's the post:

Go is boring

Go has nothing new. Go has nothing special. You've see all of Go before. You're right. I get it. But what you haven't seen is all these things together in a single language. Where they all come together to make a really damn useful core.

You've used channels before, cool. You've used the pure bliss that is the slices efficiency in a couple of other places and grew to expect the behaviour in new languages. You're proficient with threads, coroutines, actors, futures and promises. You've quacked and walked and talked like a duck. But you've never (probably) done all these things together. And that's what Go is. Go is all the things that we've always known are good, smushed together. Go tries to remove all the things that are bad about languages and erases the majority of it (or at least does a good try to give you a decent alternative).

Static typing, with all it's greatness, can make for some damn verbose code. You sit and type at the compiler what each and every variable is, you painstainkingly explain (to a computer) explicitly what each part accepts and returns. It's annoying, and mostly avoidable. There are several basic types which have literal syntax, or functions which create those types. Or special syntax. So why do we need to use the special syntax to create those types along with telling the compiler which type it is? We don't. Type inference. Go has a kind of type inference operator (:=) which will deduce the type at compile time and save you precious keystrokes. This isn't anything new, tonnes of languages do it.

Useful but light object oriented programming. There are tonnes of C++ style languages which make classes seem like the final boss of programming. Where all yours types have to be carefully categorized and laid out in neat little ways in order to create a taxinomal tapestry, a kind of zoological museum of each working object in your code. It's weird the kind of gradiose ceremony we give to the simple act of giving stuff... stuff to do . Nouns are things, nouns do verbs. That's simple as that. There should be nothing special about that style of programming. It allows certain gains. It has wonderful encapsulation of methods which operate on the same data (verbs acting on parts of the noun), it has a nice semantic use (x is a y) but it certainly doesn't have a use everywhere. Hell, I've been writing a lot of backend stuff for the web and I've not written a Python class in about... 3 months. Many languages bring OOP back down to the level of "just another paradigm", where it should be. This is nothing new.

Concurrency is a first-class citizen. This is awesome. No longer do I have to search through the standard library only to be met with an aging, creaking model which doesn't quite fit my needs. Nor do I have to use the same tired methods for making my applications concurrent. With annoying models like threads and joins and crufty things like that. Go just goes. I ask for a concurrent routine, I get a damn concurrent routine. It makes concurrency feel solved for a lowly programmer like myself. This is nothing new.

I guess my point is that, whilst on paper (and I felt like this myself) that Go may look like nothing new. Where it looks like you could get those features elsewhere and not have to care about learning yet another new-school language. You've not had them all together. Or at least this baked-in to the language.

Interesting! Could you explain why []rune needs to be wrapped in a struct{Runes []rune}? Rather then just calling "type Runes []rune"?

It doesn't need to. You could also write type Runes []rune but the struct variant has the advantage that you can get the array back without any conversions - it's pretty cheap. And you can embed it. That's an advantage if you e.g. don't define Less on Runes but define it on RunesAsc and RunesDesc. See http://golang.org/pkg/sort/ -> Examples (SortWrapper)