My problem with most singletons is that they are a half-way solution for a developer unwilling to commit and accept that sometimes a bit of global state isn't t

My problem with most singletons is that they are a half-way solution for a developer unwilling to commit and accept that sometimes a bit of global state isn't the end of the world. Static fields and static methods on classes should be used sparingly, but if you're going to use them, just use them. Why half-assedly try to hide the fact that you're using them by wrapping them into a singleton? This is a(nother) thing I like about Go, the design of the language allows for the fact that sometimes a function is just a function and doesn't need an object receiver and maybe it even modifies a package level global, so what? Just make sure you properly handle multithreading situations. In Go code you don't find a lot of patterns where people are trying to sweep what they are doing under a rug in order to not anger people who accept "common wisdom" code design guidelines as absolutes. If you need to write "dangerous" code (and sometimes it is best to write "dangerous code"), do it in the open, out in the light of day, that way at least it can more easily be reasoned about if someone does hit a snag in it.