Other articles in this series:

Position statement on Go modules

Once upon a time, I liked Go. In fact, I thought it was an amazing language — or rather, an amazing runtime, because it corresponded with my longrunning belief in the use of large numbers of asynchronously scheduled fibres for I/O, as opposed to things like the continuation passing style. The continuation passing style was originally invented with the intention of being a compiler transform; no self-respecting programmer should write in a language which expects them to write performant I/O code in such a way.

Most languages have now finally, decades late, adopted the continuation passing style as the compiler transform it was always supposed to be — usually via keywords named something like async and await to denote where the syntactic transformation should be performed. However, this creates a new problem — the red-blue function problem — and thus doesn't solve the problem entirely, whereas asynchronous I/O systems based around a special runtime, as in the case of Go and Erlang, solve the problem in a much cleaner way.

Go was the first real alternative to Erlang, which I never got into, in this regard. Stackless Python did exist, but has literally no ecosystem, meaning you would have to build all your own libraries on top of it, making it basically a non-starter.

Thus, I liked Go and rapidly came to consider it my favourite language. It was a performant, statically typed, native code language yielding high productivity and with a very high-quality, reliable runtime scalable to tens of thousands of concurrency units.

However, then Go modules were announced and Go turned to ashes in my mouth. Since the announcement of Go modules several years ago, I have suspended all new development work in Go and put the whole language on hiatus, doing only essential maintenance work.

Simply put, the Go modules is a misguided and, in my view, unacceptable proposal. My previous article “Go modules considered harmful” explains why in detail. Since golang.org have finally advanced their long-term plan to remove $GOPATH support, this post cannot be deferred any longer. This post exists to set out my position statement on Go modules and plans for the future.

Position Statement

In short:

Other articles in this series: