Porting windspeed.app to Go

I’ve been running a small web service that adds weather details to Strava activities for the past year or so. It’s a super simple Python/Flask app that I actually just forked from Yuriy Volodin, made a couple changes, and deployed it with Railway.app. It’s been working without incident ever since.

example weather stamp from windspeed.app

The Railway.app experience has been great and I really like the platform, but it’s the wrong tool for the job. Even Though there are about 200 active subscribers using the service, having a dedicated server that’s running continuously is a bit much.

I decided to refactor it into a serverless architeture that now runs on Netlify and connects to a CockroachDB sql database. Since Netlify doesn’t support Python based serverless functions I also decided to teach myself Go. I’ve been using Python basically every day for over a decade now and it recently dawned on me that I’m really tired of it. Overall I was really impressed with Netlify. Actually, the whole Netlify/Go/serverless experience has been really enjoyable. I’m clearly not a web developer, but I practically fell into a working solution within the span of a weekend.

Throughout this migration, I ended up reading two books: Learning Go: An Idiomatic Approach and Cloud Native Go. I only got about half way through the latter since many of the patterns are overkill for this, but they were both pretty good. So far, Go has been a great distraction. It maintains the readability of Python while keeping all the things I like about C.

Will Go become the Fortran of cloud services?

I certainly hope so! But I obviously can’t speak for the Golang community or maintainers, but from my very limited view, it appears that it could be and that makes me very excited. Why? I like Fortan a lot. I also know that a lot of people who aren’t familiar with Fortran often lump it in with obsolete languages like COBOL. I get why people do that, but it’s not correct. Yes, Fortran is old but its latest stable release was in 2018 and the standard library continues to get regular updates. Also, have you seen the new Fortran package manager? It’s really good! And now, thanks to LLVM you can compile to WebAssembly and run directly in the browser!

So how does this relate to Go? Well, reading through various docs and libraries I would come across statements such as:

It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification. At some indefinite point, a Go 2 specification may arise, but until that time, Go programs that work today should continue to work even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.).


- Go 1 and the Future of Go Programs (source)

Or this (gorilla/csrf):

To me, these statements suggest a much longer planning horizon than what I tend to see in the Python ecosystem, and that’s refreshing. My background is aerospace engineering, but I worked in motorsport and across these two domains, I’ve seen a lot of Fortran. Some of these code bases are older than I am, compile without error and run just fine. Probably the most obvious example is NASTRAN. Originally developed almost 50 years ago, it has since touched just about every aspect of modern life. If you’ve flown in basically any contemporary Boeing aircraft you can thank NASTRAN. At least a few of the rockets which carried the satellites you depend on for data connectivity were designed using NASTRAN. It helped design the Space Shuttle and I’ve seen it used extensively in F1/WEC. The fingerprints of NASTRAN are everywhere. Actually, now that I’m thinking about it, since NASTRAN was built using our tax dollars, it may actually represent one of the best investments we’ve ever made as a country…

And it’s not just NASTRAN, XFOIL and many other simulation codes have enough experimentally verified results they could fill a small library. I’d also be willing to bet that ECHO 1 was also written in Fortran. If you live in the US and checked the weather this morning, odds are those values came from the NOAA UFS weather model which… you get the idea. Fortran may be “old”, but it’s everywhere. Fortran represents code that will compile decades after the last update with minimal fuss.

I’ve gotten a bit carried away, but this is basically a very long winded way of saying that I’m really tired of code rot and dependency management. I’m tired of building things that don’t work a year later. I’ve got a dozen TensorFlow models currently serving production traffic at work and just dealing with those gets annoying. I can’t imagine how much functionality they’ll lose after a few years of neglect, let alone one or more decades. Yes, simulation code is completely different than stuff written for the internet but those statements and others like it capture some of the qualities that I think makes Fortran useful and relevant today. If Fortran is the backbone of scientific computing, Go may very well become the backbone of web services.

ChatGPT / Bard

Throughout the process of teaching myself Go and building out this project, I’ve been playing around with ChatGPT and Google’s lesser known alternative; Bard. Nothing I’m doing is terribly complex, but getting a second (or third) opinion has been fun. I’ll occasionally get the hallucinated nonexistent method, but overall the experience has been both positive and surprising. I know that we’re currently in the MNIST stages of LLMs but given their overall simplicity, the end result is nothing short of remarkable. For instance, to create a top tier LLM, you need the following:

That’s it. LLMs are simpler than the hardware they run on! If LLMs are to NLP what CNNs where to traditional CV (HOGs, edge detection, etc…) we might be in for an exciting ride!