You Don't Need It

About a year ago I wrote A Dismissal of the Go Programming Language. Since I've recently started using Docker in anger I've come into contact with stuff actually written in Go, which was a bit of a surprise. Even if Go is backed and pushed by Google, that's no guarantee that the language will receive any adoption outside of those forced to use it by company decree - witness Dart.

So I thought I'd do a check up of where Go had gone to; and I think I can summarize it as "Go is maturing".

Go has always chosen simplicity over just about anything else. Thus, no pre-emptive goroutines, no templates or generics or any of that fancy stuff that "you don't need", according to the creators of Go, anyway. In short, Go threw out the last forty years of programming language development, because it was judged too complicated for the "common Googler".

However, the creators of Go missed the fact that those "complicated" features were usually popular and requested because the average programmer (and on average, we're all average) found them helpful. Generics helped the average programmer avoid type errors. Exceptions would signal errors even if the average programmer missed checking the return value.

Sure, Go can be used to build big systems, even without those features. But then again, we went to the Moon in 1969 with a whole lot less computing power and tools than Go provides. Just because it can be done without a given feature doesn't mean that the feature isn't helpful or really useful.

Which gets me to what I mean by "maturing". Maturing, in the case of Go, is when all those "you don't need that" are quietly implemented or announced as great leaps forward. Take generics, for example: Officially, Go doesn't need them. Unofficially, though, there are at least two code generators (gen[a] and genny[b]) to bring generics to Go, and now there's an official go generate command to run code generators.

Will Go get generics? Yes. And I think it will be much better off. I just hope it gets a standard generics syntax, and not multiple competing implementations.

I also think Go will get rid of "magic" functions and types: being able to use range on user defined types, and other cases where the built-in functions work in ways that user-defined functions can't. Having these magic elements in the language is really the language creator giving up and saying that the rules of the language are just too restrictive.

Go sort of supports generic functions as evidenced by its built-ins[c]. You just can't implement your own. Go sort of supports generic types as evidenced by slices, maps, and channels. You just can't implement your own. Go sort of supports function overloading as evidenced again by its built-ins. You just can't implement your own. Go sort of supports exceptions as evidenced by panic and recover. You just can't implement your own. Go sort of supports iterators as evidenced by ranging on slices, maps, and channels. You just can't implement your own.

— Tyler Treat, "Go Is Unapologetically Flawed, Here's Why We Use It"[d]

If I'm wrong, and Go doesn't mature, it will be the next Pascal. A language that set out to keep beginners safe, but ended up being overprotective and too restrictive to be of general use.