bhollis

This is one of those "easy" things that should really be built into the CSS standard (as Josh points out in the article).

Neat, they have Newt, the robot my dad built that was the first mobile robot with its own onboard computer. Newt is still there in his basement, and as a kid I did science fair projects programming behaviors for it. At that point the computer had been upgraded to a Motorola 68K. https://www.theoldrobots.com/Newt.html

An incorrect assumption (though it was nice to have seen a familiar face when I came across it) but good to know what you think of it. I assumed HN deduped posts but I guess not.

I've found that once you make the jump to a real partitioned datastore (like DynamoDB) you can actually go back and undo a lot of the queues and caches that were used as band-aids to reduce pressure on the DB. If you have something that has consistent performance at any scale and true elasticity, you just don't need all that other stuff, and the whole system gets far easier to understand and operate.

The pattern I've always used for this, which I suspect is what they landed on, is to have an optimistic notification method in a separate message queue that says "something changed that's relevant to you". Then you can dedupe that, etc. Then structure the data to easily sync what's new, and let the client respond to that notification by calling the sync API. That even lets you use multiple notification methods for notification. None of that involves having to have the database coordinate notifications in the middle of a transaction.

Slow startup was definitely one reason to have long lived servers, but I’m surprised not to see the major other reasons:

- Keep-alive/pooled connections to remote services can significantly reduce average latency for making those calls.

- In-memory caches that allow amortizing repeated lookups across requests.

Just those two alone mean that a serious high performance server probably couldn’t get away with just CGI even ignoring startup time.

The flip side of technical debt is, what tools do you have to actually solve technical debt? Some technical debt comes from conscious decisions to choose an expedient solution over a long term one, but a lot of it just comes from not knowing what the future is going to bring, and not wanting to over-engineer for every possible outcome.

The question I'd ask is, shouldn't we have tools that make it super easy to change things, so we can adapt to different outcomes without it becoming a huge slog?

We're using Go, so cross-compilation has never been a big problem (for producing artifacts). But this'll be great for testing on ARM. I'm interested to see the performance of these instances too - our experience has been that Amazon's Graviton processors have fantastic bang-for-buck vs. Intel/AMD.