[locknitpicker]

> There is a good reason: teaching yourself not to over-engineer, over-provision, or overthink, (...)

This is specious reasoning. You don't prevent anything by adding artificial constraints. To put things in perspective, Hetzner's cheapest vCPU plan comes with 4GB of RAM.

[sgarland]

If I give you a box with 1 GiB of RAM, you are literally forced to either optimize your code to run in it, or accept the slowdown from paging. How is this specious?

[filleduchaos]

Why not a box with 128MB of RAM then?

[sgarland]

Aside from the perfect solution fallacy, pragmatically it's because most operating systems require more than that to run. Debian's current recommended minimum is 512 MB, though they note that with swap enabled, as little as 350 MB is possible. If you wanted to run something more esoteric like Damn Small Linux, it's possible with as little as 64 MB last I checked.

In any case, this is for the OS itself - the webserver, application, database, etc. will all of course require their own. For a well-optimized program with a well-optimized schema, 1 GB is a reasonable lower bound.

[filleduchaos]

Oh I'm well aware of the existence of operating systems that run in 32MB of RAM or less. So - why not? I think a well-optimised application server (especially one that uses SQLite as a datastore like the article proposes) can fit just fine in 128MB of RAM total, or 256MB if we're being generous. A whole gigabyte of memory seems rather extravagant, no? You could run half a dozen properly optimised apps on such a box.

[locknitpicker]

> If I give you a box with 1 GiB of RAM, you are literally forced to either optimize your code to run in it, or accept the slowdown from paging. How is this specious?

It is specious reasoning. Self-imposing arbitrary constraints don't make you write good, performant code. At most it makes your apps run slower because they will needlessly hit your self-impose arbitrary constraints.

If you put any value on performant code you just write performance-oriented code, regardless of your constraints. It's silly to pile on absurd constraints and expect performance to be an outcome. It's like going to the gym and work out with a hand tied behind your back, and expect this silly constraints to somehow improve the outcome of your workout. Complete nonsense.

And to drive the point home, this whole concern is even more perplexing as you are somehow targeting computational resources that fall below free tiers of some cloud providers. Sheer lunacy.

[ufocia]

The gym analogy fails. Isolation exercises are almost exactly what you described. They target individual muscles to maximize hypertrophy, i.e. "improve the outcome of your workout."

[sgarland]

Constraints provide feedback. Real-world example from my job: we have no real financial constraints for dev teams. If their poor schema or query design results in SLO breaches, and they opt to upsize their DB instead of spending the effort to fix the root problem, that is accepted. They have no incentive to do otherwise, because there are no constraints.

I think your analogy is flawed; a more apt one would be training with deliberately reduced oxygen levels, which trains your body to perform with fewer resources. Once you lift that constraint, you’ll perform better.

You’re correct that you can write performant code without being required to do so, but in practice, that is a rare trait.