Go is Weird

Go is weird. For all its intended (and frequently achieved) simplicity and straightforwardness, I keep being surprised by its rough edges and seemingly arbitrary corner cases. Here is one.

Who is Responsible for Writing Go Interfaces, Anyway?

For every function, data type, or other such code artifact, there are two bits of code: the part that defines and implements it, and the one that uses it.

As I have been thinking (here and here) about the proper use and understanding of Go’s interface construct, the question came up, who is actually responsible for writing the interface: the person who defines the data type, or the person who uses it?

Indispensable Project Management Artifacts and Activities

I was recently reminded of the minimal set of project management artifacts and activities that are, in one way or another, simply indispensable.

None of this is news: all of this has been well established for at least 25 years (a quarter-century!), so I was surprised that apparently it is still not common knowledge or practice — at least not as common as one would wish for.

Go Interfaces and the Handle/Body Idiom

The interface construct in the Go language is one of its most immediately visible features. Interfaces in Go are ubiquitous, but I am afraid that the best way to use them has not yet fully been explored. Moreover, in practice, Go interfaces seem to be used in ways that were not intended, and are not necessarily entirely beneficial, such as an implementation shortcut to the classic Handle/Body idiom that hides interchangeable implementations behind a common, well, interface.

Laplace's Theorem

Let $G$ be a finite group with $n$ elements, and $H$ a subgroup of $G$ with $m$ elements. Then $m$ is a divisor of $n$: for a finite group, the order of any subgroup divides the order of the group.