Will expensive RAM change how we code?

Due to shortages, RAM is very expensive right now. And it will probably continue according to (somewhat optimistic) forecasts.

Hardware is now expensive to the point that some serious Cloud providers already raised their prices drastically. Even for very competitively priced providers like Hetzner: some of their "Cloud servers" have more than doubled in price! A big player like Apple now considers raising the prices on its products and we may assume hyperscalers (AWS, GCP, Azure) will follow sooner or later.

Running software is now much more expensive than before.

If this situation continues for a long time, how would it change our behavior and culture of software efficiency? Will we defeat Wirth's Law (which states that software is getting slower more rapidly than hardware is becoming faster) by writing software that squeezes out every single droplet from cheaper and older hardware we will keep?

What if RAM stays expensive after 2027?

Durable economic pressure tends to change behavior. If RAM stays that high and the whole ecosystem adjusts to it, then maybe developers will adjust too by changing their code and trying to deploy their software on cheaper and/or older instances with less memory, or cheaper and slower memory.

CTOs today sometimes ask engineers to be careful about egress bandwidth and optimize it, because that costs money. I could totally imagine a CTO asking the teams to be more careful about RAM usage too, and have software optimized to be deployed on modest instances instead of higher specs instances with more headroom. Same for teams using serverless products (AWS Lambda, Cloudflare Workers, ...) since they are generally charged as a factor of memory × duration.

A (maybe not so) fictional scenario

Many popular production languages are not known for being particularly frugal with memory (Python, Ruby, JavaScript, JVM, ...) because this is usually not a top priority for the teams using them, nor for the maintainers. Changing an entire stack and rewriting software in Rust or Go would be a bit extreme and costly, but maybe it'll at least raise awareness among developers of efficient patterns to reduce memory usage, e.g.,

Believe me, in my career I've seen a lot of horrific code written with the assumption the CTO will continue to rent more high-end 128GB dedicated servers if too many OOM errors occur... Zero respect for hardware, entire tables loaded into the heap, huge lists kept in memory at every stage of the processing pipeline (no iterators at all). The team didn't care much: developer time was too expensive and hardware was cheap back then in 2018 or 2019.

This is an extreme case and not the norm (well, I hope so), but I wouldn't say doing the exact opposite is the norm either. But maybe it'll change at least for the early-stage companies that cannot afford not to be frugal before making serious money like my previous company did.

As for the runtime and language implementation side, I believe maintainers may consider memory optimization as priorities in their roadmap. In our current timeline, CPython, Ruby, GraalVM and others have already been improving memory, but it was never a stated priority. It may change. Those efforts were not related to the memory chips shortage and price increases per se, but it could be a stated priority in the future in such a scenario.

Maybe the era of writing software as if RAM is free is coming to an end...