This is a lengthy post explaining my reasoning for certain decisions we’re making in the Go subreddit. It is posted primarily to share with other moderators of all sorts of content as we all struggle through the implications of AI. If anyone else gets any benefit from this, that’s a bonus. For anyone else uninterested in that, you know where the back button is. When I agreed to be a moderator on the Go subreddit a couple of years back, I didn’t expect to be on the frontlines of dealing with AI’s impact on human online communities.

As it stands today, consciousness is a black box of mystery. We don’t know how to define it, we don’t know how to measure it, we don’t have any terminology for it, we comprehensively lack any framework for dealing with it. We operate on “we know it when we see it” standards, and if you go down the P-zombie line of thinking, you may be reduced to “we know it when we experience it”.

In my previous post, Layered Design in Go, I discussed a procedure that can be used in any Go module to order the packages in an order of what depends on what, starting with the modules on the bottom that have no internal dependencies, then the modules that only depend on those, and then so on. Conceptually it’s a useful way to think about Go modules, and any other system that similarly forbids circular imports.

This post will describe how I design my programs in Go. I needed this for work, and while I searched for a link, nothing quite fits my coding practices out there. The word “Layered” can pull up some fairly close descriptions, but I want to lay out what I do. Deriving Some Requirements Go has a rule that I believe is underappreciated in its utility and whose implications are often not fully grasped, which is: Packages may not circularly reference each other.

As many others observe as well, one of the major reasons to write is to firm up ideas in one’s own head. Serializing an idea out into English words is still no guarantee one understands it deeply, but it is great progress over a very fuzzy idea that has never been fleshed out at all. I’ve known for a long time I wanted to sit down and write this out. But I had no idea how many principles I’ve either drawn out from my times with functional languages, or had sharpened by them forcing me on to certain paths that perhaps I would have walked eventually, in bits and pieces, but functional programming forced upon me in toto.

I am reliably informed by many people that the core essense of functional programming is the extensive use of map, filter, and reduce, that these functions are superior to for loops in every way, to a degree that they should be jammed in to every possible language with no need to analyze the cost/benefits of such an approach because the benefits are just so incomparably amazing that the costs couldn’t possibly be relevant, and even wondering about the costs just proves I Don’t Get It.

Up to this point I have not followed through on my promise to offend everyone in general, and in particular, functional-programming-in-imperative-languages advocates. Everything’s been pretty positive about functional programming. This is where the tide is going to start to turn, but I’m going to lead into it a bit before getting really offensive. “Programmable Semicolons” Let’s talk about monads, and in particular, monads in their capacity as “programmable semi-colons”. If you understand why monads are “programmable semicolons” it’s a reasonably good sign you have a good understanding of them.

Functional programming languages see types not just as buckets of things that can contain values, but as assertions, e.g., this is not just a string that I vaguely hope is a Username, but this is a validated, certain-to-exist Username for a user, and anything that receives an input parameter to some function that is a Username need not run its own validation code on the Username to ensure it is valid, and thus also doesn’t need an error path for invalid Usernames.

At the beginning of this series, I said I was going to annoy every programmer in the world in some way or other. So hang on, here comes one of those super hot takes that I was promising: Global variables… are bad. Alright, for those of you who were not so offended that you instantly snapped your browser window shut, obviously I am aware that this is not news. The higher-skill end of the programming world was well aware that global variables are dangerous since before functional programming1 was even conceived of.

This is another lesson that does not require functional programming to notice, but it is a lesson that functional programming puts front and center whereas independently discovering it from imperative programming may take a long time. Functional programming derives (pun intended) a lot of benefit from its typeclasses, despite them in some sense being second-class citizens in the expression problem to sum types. Much code is written against small interfaces like “functors” or “monads”, which can then be applied to any value that fits into those interfaces.