In several debates online about function colors over the years, people have argued the apparently reasonable position that function arguments can constitute colors as well.

For instance, in Go, there is a context.Context value, which manages timeouts, cancellation, and a small amount of data that can be threaded through various functions. It is, by design, intended to be something passed through functions even if the receiver doesn’t use it directly but only passes it along. Generally, once one function starts using a context, you should thread it along to all called functions that could conceivably have a use for it.

The effect of AI on PRs has gotten a lot of press. Slop PRs, untested PRs, just the profusion of PRs. Slop bugs, slop security reports, all sorts of slop problems. Definitely a problem.

But I would also propose that something else happening in the open source space that is hurting the open source community: Everyone thinks they can start their own project now. The stream of web frameworks, proxy servers, and all of the other code projects that we frankly had too many of even before AI has accelerated even more. Everyone seems to think they can run their own project now.

One of the recurring hobbies of the programming community is to self-righteously self-flagellate about how we don’t do Real Engineering^TM like those other engineering disciplines do, with their blueprints, and licensing processes for Real Engineers, and planning, and site testing, and all their wonderful formal processes that we so callously ignore. If only we could do more planning up front, and be more careful about what we’re doing, and copy all that other stuff they do, we could have better software that didn’t break as often.

As with many programmers, as my career has progressed I’ve come to appreciate the utility of “compile time checking”. I don’t ever want to go back to a language where it is hard to verify constraints are checked at compile time.

Followers of this blog may know that I do a lot of programming in Go, and find it hard to square that attitude with the use of Go, which has relatively weak compile-time guarantees.

Two strands are making me ponder the “value” of code in our new AI era. One is the increasing cheapness of producing a line of code, trending toward zero. As a professional who produces lines of code, among other things, this trend is something I need to be thinking about for many obvious reasons. The other is the question of how to moderate a Reddit programming community in a way that keeps the community as healthy as possible.

Every field of human activity has its unique characteristics, and programming is no exception.

One of the unique aspects of software is how it spans such a large number of orders of magnitude. A software engineer may be slicing and dicing nanoseconds, or they may be trying to accelerate a computation that will run across thousands of cores for a month… and they may even be doing both at the same time!

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. My brain doesn’t do chronologies very well, so I don’t recall if it was entirely before ChatGPT was a thing, but if it was a thing, it was back when its programming abilities were laughable. There was a time not so long ago when one could ask ChatGPT to code something, and you could see that there was some promise there, but at the same time, it tended to have difficulty putting out so much as a single line of syntactically-correct code, let alone code that did what you wanted.

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. It is strictly forbidden. A compile error.