Having done extensive programming in C, I am not particularly spoiled when it comes to idiosyncrasies of a language’s “string” type. Yet, Go’s string types keeps tripping me up — why does it all still have to be that complicated?
Go request handlers typically include a “context” value as their first argument:
func handler( ctx context.Context, ... ) {
...
}
In my experience, this convention is typically fastidiously followed, but
then nothing is ever done with that ctx argument. What is it really
for? Unfortunately, the description in the official
Go package documentation
is a bit cryptic, and the type implementation itself does not reveal
anything either (the default context is just an empty struct).
Properly understood, it’s actually a really convenient idiom; however,
its value is not so much in the context package itself, but in some
idioms in the code that use the package.
Every once in a while, I need to evaluate the normal distribution function $\Phi(x)$:
$$ \Phi(x) = \frac{1}{\sqrt{2 \pi}} \int_{-\infty}^x \! e^{-\frac{1}{2}t^2} \, dt $$
Unfortunately, it is not always available in the standard math libraries, and hence I have to implement a “good-enough” version myself. Here are some options.
I have never seen a software project in which the limiting factor was the speed with which programmers could type.
The extended Berkeley Packet Filter, or eBPF for short, is a plugin architecture for the Linux kernel. Using eBPF, it is possible to load (short) programs into the kernel at runtime, and have them be executed by the kernel. As the name suggests, the technology started out as a method to build custom filters for network packets, but it has since been extended and become much more general.
Imagine a bunch of wood chips randomly distributed on a surface. Now add an ant, randomly walking around amongst the chips. Whenever it bumps into a chip, the ant picks up the chip; if it bumps into another chip, it drops the one it is carrying and keeps walking.
How will such a system evolve over time?
A tool to display directory entries, sorted by size, together with their cumulative contribution to the total.
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.
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: