Congrats on the traction you’ve got with this project. We used Gin back in 2016 for a while. I honestly don’t understand those Go devs who claim that the standard library is sufficient for building a serious API — there’s still so much boilerplate, and you end up writing your own mini-framework anyway.
The main reason we don’t use it anymore is that the default handlers don’t return the error type, which means error handling and HTTP status tracking get tricky and non-idiomatic as soon as your handlers start calling functions that can fail. It’s essentially a function coloring problem.
One could argue that HTTP status is a totally separate thing from normal errors, and I get that perspective, but that’s a significant ergonomic hit to take for the sake of philosophical purity.
I don’t know about the company’s ethics*, but the app is fine and it’s genuinely useful. For one thing, it has a map with the most popular running routes around you. And if you want to be part of an exercise community in the US or Europe (at least UK), it’s the only game in town.
*Strava is one of the worst apps I’ve seen in terms of aggressively upselling you to a subscription. Genuinely infuriating.
Have you tried https://github.com/simulot/immich-go for dealing with the some of the complexity of google takeout? Not sure how much it actually handles, and whether it can be used easily if you're not migrating to immich, but it's what came to mind here. (I'm a new user of immich but never used google photos)
It’s not about ease of use and freemium, it’s the strong network economies at play, just like credit cards or social networks. It’s impossible for a competing product to get traction if it’s merely a little better than GitHub.
This is the real issue. We’re currently migrating from GitLab+Jira to GitHub. I did most of the migration, including our CI/CD with a self-hosted runner, and it was… fine.
The straw that broke the camel’s back was that Claude managed cloud agents are awkward to use with anything other than GitHub. In general, we realized that the whole world was on GitHub and we were swimming upstream.
But the original mistake was separating issue tracking and source control when we didn’t need all that power. Everything is so much simpler if you don’t have to maintain those integrations.
Maybe they’ll really enshittify GitHub in the future. We’ll cross that bridge when we come to it.
I literally maintain a conceptual-model.md that describes the “things” in our entire system, how they relate to each other, and some bits about how that maps to the code (the DB schema maps sort of closely to it but sometimes not that close, and so does the API, and that’s ok). I wrote most of the doc myself, but plan to coauthor with LLMs going forward.
So far it’s saved me tons of typing as I add features. I don’t have enough data yet on how well it will guide myself and others when adding stuff that really stretches the model, but I’m also optimistic that it’s a valuable approach.
As someone who’s an experienced coder but sorta new to LLMs, I’ve learned that my intuition about what is and isn’t machine-readable for an LLM isn’t well-tuned. Better to do the benchmarking so you can be sure you’re not fooling yourself about whether use of YAML is warranted.
From the perspective of the “physics” of code (for lack of a better term), this feels right. We all know that if you have a generated asset, you basically mark that asset as read-only or you’re entering a world of pain. As more and more code is generated, the same forces will apply.
Harder for brownfield projects of course (and it basically replaces Jira, which would cost me all my social capital if I try), so I won’t be adopting it now. But I will be leaning into long-lived organic, grass-fed assets like conceptual-model.md that‘s critical for evolving the product forward but doesn’t strictly map to the types in the code.
I really enjoyed engaging with the article. Loved the humor sprinkled in, and the humility demonstrated throughout. Some great first-principles clear thinking here.
Every now and then someone shares a small web link here (Kagi is one aggregator). It’s like survivors picking up the shards of civilization after the apocalypse. Of course such a project can remain viable and useful as long as it remains niche, which is virtually guaranteed as long as there’s no money in it.
It’s incredible how too much money corrupts everything it touches.
I switched to Linux in 2018, and I hear you on the quirks. But now, an LLM can fix basically any quirk you hit. I’ve been surprised multiple times. I’m also on Pop OS, which feels more batteries-included than Ubuntu.
There are differences across vendors, but there’s a way to build with k8s where the benefit far outweighs the cost.
We run a bunch of services in two very different cloud vendors (one of which used to be DIYed with kubeadm), and also on dev machines with k3s. Takes a while to figure this out and to draw the kustomize boundaries in the right place, but once you do, it’s actually really nice.
Two things work in our favor:
- we’ve been at this for around 8 years, so we didn’t have to deal with all the gotchas at once
- we aggressively avoid tech that isn’t universal (so S3 is OK, but SQS or DynamoDB is not; use haproxy instead of ingress controllers; etc)
That part was really surprising to me because for the kind of compute lake he’s talking about building, k8s seems like a pretty good fit for the layer that sits just above it.
We run k8s with several VMs in a couple different cloud providers. I’d love it if I could forget about the VMs entirely.
Is there a simpler thing than k8s that gets you all that? Probably. But if you don’t use k8s, aren’t you doomed to reimplement half of it?
Like these things:
- Service discovery or ingress/routing (“what port was the auth service deployed on again?”)
- Declarative configuration across the board, including for scale-out
- Each service gets its own service account for interacting with external systems
- Blue/green deployments, readiness checks, health checks
- Strong auditing of what was deployed and mutated, when, and by whom
Was just listening to the Lenny’s Podcast interview with Simon Willison, who mentioned another such incantation: red/green TDD. The model knows what this means and it just does it, with a nice bump in code quality apparently.
I’m trying out another, what I call the principle of path independence. It’s the idea that the code should reflect only the current requirements, and not the order in which functionality was added — in other words, if you should decide to rebuild the system again from scratch tomorrow, the code should look broadly similar to its current state. It sort of works even though this isn’t a real thing that’s in its training data.
I have a Supernote and was looking at different models for handwriting recognition, and I agree that gemma4-26B is the best I’ve tried so far (better than a qwen3-vl-8B and GLM-OCR). Besides turning off thinking, does your setup have any special sauce?