HN user

physicles

1,778 karma
Posts2
Comments623
View on HN

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.

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.

Mythical Man Month 2 months ago

I love that Naur paper! Also love this essay that extends it: https://hiringengineersbook.com/post/autonomy/

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.

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.

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?

This is in fact what happened with SpaceX. Musk had the vision to make first stage reusability a thing with the Falcon 9, and Gwynne Shotwell is the operational genius behind the juggernaut that it is today.

Hilarious quote from her Wikipedia page:

Shotwell has received particular praise from NASA Administrator Bill Nelson for her "phenomenal" leadership of SpaceX as it developed the Falcon 9 into the "workhorse" of the space launch sector.[19] Nelson had reportedly been concerned in 2022, after Elon Musk purchased Twitter, that it would be a distraction at SpaceX, but became more comfortable after meetings with Shotwell left him feeling reassured that she was in charge of day-to-day operations.

The idea lingered for longer than that. China under Hu Jintao wasn’t exactly friendly to the west, but it was Xi who really set China on its present course to build a multi-polar world, make real noise about reunification with Taiwan, etc.

This new direction didn’t become clear to both sides of the aisle in the US until a year or two into Xi’s tenure. If someone else other than Xi had been chosen, we would likely have a very different China today.

For sure. I feel I need all of my experience to discern the difference between “slightly different, and should be combined” and “slightly different, and you’ll regret it if you combine them.”

One of my favorite things as a software engineer is when you see the third example of a thing, it shows you the problem from a different angle, and you can finally see the perfect abstraction that was hiding there the whole time.

I’m one of those that have thrown out Postel’s law entirely. Maybe the issue is that it never defines “strict”, “liberal”, and “accept”. But at least for public APIs, it never made sense to me.

If I accidentally accept bad input and later want to fix that, I could break long-time API users and cause a lot of human suffering. If my input parsing is too strict, someone who wants more liberal parsing will complain, and I can choose to add it before that interaction becomes load-bearing (or update my docs and convince them they are wrong).

The stark asymmetry says it all.

Of course, old clients that can’t be upgraded have veto power over any changes that could break them. But that’s just backwards compatibility, not Postel’s Law.

Source: I’m on a team that maintains a public API used by thousands of people for nearly 10 years. Small potatoes in internet land but big enough that if you cause your users pain, you feel it.

In Slack it can get even worse.

If you turn on Markdown formatting, shift+enter adds a new line, unless you’re in a multi-line code block started with three backticks, and then enter adds a new line and shift+enter sends the message.

I can see why someone thought this was a good idea, but it’s just not.