Will Murphy's personal home page

I Guess I'm Both?

Recently, fly.io announced that adding GPUs to their platform isn’t really paying off¹, and, unsurprisingly, there was much discussion on Hacker News². In said discussion, the top comment divides developers into two camps:

I’m increasingly coming to the view that there is a big split among “software developers” and AI is exacerbating it. There’s an (increasingly small) group of software developers who don’t like “magic” and want to understand where their code is running and what it’s doing. These developers gravitate toward open source solutions like Kubernetes, and often just want to rent a VPS or at most a managed K8s solution. The other group (increasingly large) just wants to git push and be done with it, and they’re willing to spend a lot of (usually their employer’s) money to have that experience. They don’t want to have to understand DNS, linux, or anything else beyond whatever framework they are using.³

The Dream of DJ Rafe

Dear Music Apps (most recently Spotify),

I don’t want an app about music; I want an app about soundtracking my life. Sure, being able to pick songs and follow artists is OK and all, and should probably be a feature of the app I’m imagining, but it’s not the app. It’s the “manual override” mode in the app, the time in Google Maps where you add towns you don’t actually want to stop in to Google Maps to trick it into directing you around a bridge you’d rather not deal with at rush hour. It’s the exception to my use of the app, not the rule.

Closing the Loop on Go Iterators

The alternatives to go iterators (AKA go range-over-func experiment) are all worse.

The situation I have is: I have a struct that represents a large collection of large structs, and I have a few reasonable requirements:

1. Encapsulation: clients of this package should not be able to mess with the collection; its members are validated and sorted in some way
2. Iteration: clients of this package need to be able to make a subset of the collection, hunt through the collection for a specific item, etc. In general, clients need to be able to loop over the collection.
3. Performance: the collection and its members are large, but the application is time and memory sensitive, so I don’t want to copy large slices
4. Simplicity to consume: clients of this package should not hate me.

We’ll look at some examples of things I could try to meet these requirements, and see why all of them fall short in some way without using go iterators.