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.

Django REST Framework has two methods for writing APIs - function based views (similar for people coming from other frameworks like Flask or FastAPI), or class-based views (which is more like the patterns in the ASP.NET and Spring frameworks). Class-based views seem to have won out within the Django community, and so here we will focus on those, but even after making this choice, developers still need to decide which type of class-based view is appropriate.