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?
In response to a previous post, very insightfully, Steve Singer, pointed out that it is helpful to distinguish between three concepts, when talking about “interfaces” in general:
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.
They use a “real database”. They use “nice object-oriented libraries”. They use “nice C++ abstractions”. And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess.
When writing programs that do computations, my overwhelming preference is to simply write results to standard output, and to use shell redirection to capture the output in a file. In this way, I am leveraging the shell’s full functionality, in particular filename completion, in the most convenient way possible. For the file format itself, I prefer simple, column-oriented, delimiter-separated flat files. They are completely portable, and can be read and understood by most tools. (They also play well with the usual Unix toolset.)
But this simple approach breaks down, once a program has to write more than one output stream: for example in the case of a simulation run, I may want to capture periodic snapshots of the simulation itself, but also track various calculated metrics as well. These two streams will not fit comfortable into a single flat file. One option is to use a structured file format, the other option is to write to multiple files simultaneously.
Among my favorite features of the Go language is the fact that Go has concurrency and network programming “natively” built in. It reflects Go as being designed for the 21st century, where the network is as much taken for granted as the filesystem was towards the end of the 20th.
As cut-n-paste examples, here are skeleton implementation of both an HTTP server and an HTTP client. These implementations are intentionally bare-bones, so as not to obscure the most relevant points. It should be easy enough to extend them as desired.
Imagine a shared resource, such as a compute server. Users can submit jobs to the server. The resource is “free”, in the sense that no costs are imposed on the users. The question is how to best assign and prioritize jobs when multiple users submit jobs simultaneously.
This site is generated using Hugo. Getting the site up and running was nothing short of a nightmare, which I have documented elsewhere. But things are working now, and Hugo makes adding new content very easy indeed. It therefore seems a good opportunity to reflect back and revisit the whole “Static Site Generator” a.k.a. “JamStack” topic, from a greater distance.
Feedback is ideal for controlling large, complex systems, but its use in software engineering raises unique issues. This book provides basic theory and lots of practical advice for programmers with no previous background in feedback control.