I first started touching Python while coming towards the end of a Master’s project, about ten years ago. Much has changed over that period, and looking back, it’s kind of amazing how far we’ve come. Python has its fair share of critics out there on the internet, and obviously no tool exists in a vacuum, so many of the comparisons and criticisms are warranted as other languages and tooling have come along, but personally, I still find it incredibly powerful.

The BBC has an excellent radio programme called ‘A Good Read’. It first started 1977, and there have been hundreds of episodes, each of which has several celebrities and authors recommending a book each along with the host. Many episodes (though not all, the online archive goes back to roughly the early 1990s) are hosted for free to listen to on the BBC Sounds website. I often like to listen to it, but couldn’t find anywhere that the books had been recommended were listed online.

Go first came onto my radar about 9 years ago when I came across MuMax during my PhD studies. While I’ve touched it briefly, I wouldn’t consider myself to have used it in anger until recently, when I started a job that uses it as one of it’s primary languages for API development. I’ve had experience in writing C and C++ code, but more recently I’ve done a lot of Python, so going back to Go has felt oddly like a throwback to those compiled languages I’ve used before, with a bit of modern sparkle.

When writing numerical software in Python, there is a somewhat overwhelming array of options for tackling performance issues. From experience, it’s very hard to actually evaluate which of these options is “best” for performance without actually trying them in a specific scenario, and to understand what is happening requires an understanding of both the Python, NumPy, and lower level language’s call stack, the input arguments of the particular routine, and the system on which the code is designed to run on.

Alpine Linux is a distribution that is designed to be lightweight. In particular, it’s seen a lot of use in Docker images because the resulting image bundles are considerably smaller than those generated by other minimal distros. However, in the context of building a Docker image for a Python application, it’s worth thinking carefully before using Alpine, as it can often result in slower builds and counterintuitively it can even result in larger images occasionally.