You're using IE. Scroll down.
home :: tech :: golanground2

Golang round 2

A while back I wrote a critique of golang based on the introductory examples. The premise was simply I should be able to read it without reading the language spec and it didn’t pan out well. The result was more anecdotal than relevant. Now I committed to reading the docs and doing a real project in go.

I came into this after some investigation into clojure’s core.async. While like mostly everything in lisps core.async is written on top of the language in Go channels and coroutines are baked into the runtime which gives it blazing fast speed. It was so fast I thought it was broken.

The syntax is still confusing at parts and things like := vs = is just compounding the = vs == problem. The lack of named and default parameters is a bit vexing on a modern language but workable. The seemingly arbitrary new vs make and the hidden pointers make for some confusing surprises. I’d also expect some built in support for creating data pipelines but programs need to create all the necessary scaffolding for common patterns like map/filter/reduce. Third party libraries like GoFlow introduce flow based programing and fill the gap but being channels such a central feature the language should cover pipelining better.

This is getting data from a non trivial JSON structure in Go, minus proper error handling.

Go is strongly typed and the solution for dealing with JSON objects is going through Go’s void type, the generic interface interface{}, and then using an akward switch construct to cast to the correct data type. When the schema is well defined the JSON library allows you to unmarshal the data directly into structures but for unstructured data is this is the idiomatic way.

Using the “any type” trapdoor is sometimes necessary but when it’s a pattern it’s a sign something is wrong. It struck me when I read about copying and appending to arrays and discovered it’s a builtin. Why a builtin and not a method of slice ? Because the type system doesn’t allow it!


The Go type system doesn’t allow append to be a method and doesn’t allow program code to have generic methods. The type system makes us, the programmers, second rate citizens in the language. We can’t extend the language in meaninful ways like writing a list implementation or higher level functions without going around the type system with interface{} and writing our own runtime type system.

Some languages allow generics or templates to tackle this, others like Haskel have a type system with both type variables and enumarated types. So far Go offers cpp on steroids enabling template preprocessors. Such deliberate avoidance of generics makes golang turn into what it hates most.

/tech | edited on 2015/11/01 -- permalink, click to comment
blog comments powered by Disqus