- everyone assumes their program / website is the only thing running at the machine at a given time, and dev machines are always more powerful than user machines
- it's not really lack of advanced data structures and algorithms that result in the bloat most of the time but the fact that programs and websites are delivered by large teams, there are dozens of submodules that are often loaded even when not needed, and doing it properly is hard to architect to without getting into big complexity and gnarly bugs waiting to happen when someone from other team modifies something and does not know full picture. So it's cheaper to just keep things the way they are to reduce complexity of architecture and fragility.
The main place RAM usage is going to get optimized is on the server side, because the client's RAM is a tragedy of the commons. If you're reducing RAM usage while your competitor adds features then the extra RAM saved by your app will just be silently allocated to theirs, the device won't feel any different and the user will prefer your competitor. There is little incentive to optimize RAM usage on the client side because it only helps other companies, so nobody does it - except (ironically) browser devs, who tend to assume they have first dibs on all the RAM of the device.
If you really wanted people to care about it OS devs would need to surface memory usage of apps visibly in a way ordinary users can understand and translate to customer feedback forms, which is difficult.
If you're reducing RAM usage while your competitor...
This is true so long as client-side (desktop, mobile) memory management does not penalise high memory use.
I'm already taking the approach of killing off my largest browser processes regularly, and need to look at more targeted ways of managing memory. I'd really like to see the parent browser process as a lightweight manager over subprocesses such that it can persist (rather than leaking multiple GB of RAM over the course of days), to the point my entire user session falls over with stunning regularity.
I have a shell script (currently triggered manually, hopefully subject to further refinement) which kills off the ten top browser processes. I'll often run that in a shell loop of 10--20 iterations. It barely keeps things manageable, and system hangs/reboots are still far more common than I'd like.
The way to change behaviours is to change costs. This is where OS devs have a choice before them, and application and remote service / SaaS devs and project managers might eventually start feeling the pain.
One reason I favour HN over numerous other options is that the site doesn't absolutely pig out my browser session(s).
And that said, if anyone has tips on both revealing and managing memory usage in Firefox, I'm quite receptive.
> The main place RAM usage is going to get optimized is on the server side
Agree, but it's going to be a long, hard, potentially ultimately unsuccessful uphill slog. I think the main obstacle is basically 2 decades of inertia. Approximately everyone believes that server side software needs to scale horizontally. So we optimize systems for this property--I can make it work better by just throwing more computers at it. This was a lot more important ca. 2004 (MapReduce) than it is ca. 2026. For resiliency and redundancy, how many nodes does your service actually need? If you're running more than that number, do you have some kind of justification as to why? This is the mindset we need to try to move towards, but it's very different from how we currently do it.
EDIT: Another good question to ask, which we don't do enough: "does it really need to be a separate service?" Using data in RAM that's already been allocated is probably better than allocating more and shipping data over the network...
FWIW I work part time on projects that are all about reducing RAM usage server side! RAM has been a big expense in the cloud for a long time. AI makes the situation critical but there's a lot of work done already. Consider that functions-as-a-service are basically all about shutting down idle servers to reclaim their RAM.
FaaS are really interesting, because the tradeoffs seem "jagged" (to use a word I learned recently). Like, IIUC this is more or less what's happening when a cloud function is invoked:
1. Some event triggers the function (HTTP request hits load balancer or whatever)
2. A VM is loaded from NVMe (possibly on another computer, and transferred over the network) into RAM
3. That VM boots up
4. The function code runs
5. The VM is terminated
Naively, this probably takes a lot more RAM (not to mention all the other computing resources) than to just have another HTTP handler sitting idle on some computer somewhere.
So this is only a reasonable choice if doing this intensive computation for a short amount of time, and using a large amount of resources for that short amount of time, is somehow better than doing a much smaller amount (maybe none at all) of computing over a longer amount of time. It's kind of hard to tell what the actual conditions are that merit one solution over the other. The other layer is the cloud pricing model, but that's a whole other can of worms..
I have yet to encounter a system that didn't have at least some computers (or cloud instances) that always need to be running. Those computers are almost always a bit overprovisioned (not using 100% of their CPU or RAM or IO all the time). So it has always seemed to me that instead of running a cloud function, it would be cheaper in terms of compute resources to execute the code from step 4 above on one of those machines.
Obviously we have cloud functions for a reason, people like them and find them useful. But is there ever a regime where they're optimal?
EDIT: I guess I've implicitly assumed the code in step 4 is doing a small amount of work. Maybe there's a goldilocks zone of work-per-invocation where this model is more optimal? But then of course there's always the standard executor pool model, and that way you don't have to spin up a VM per task invocation...
> the fact that programs and websites are delivered by large teams, there are dozens of submodules that are often loaded even when not needed
Precisely this. We had an incident once where a CSV had a postal code field be interpreted as an integer by pandas, which of course results in stripping any leading 0s. After looking at what the code needed to do, I asked why they were using pandas in the first place, as it was literally just “read the CSV as-is into a list.” Guess what Python’s stdlib csv module doesn't do? Type inference.
Instead of replacing the unnecessary pandas import (which brings along a fairly heavy transitive chain) with stdlib, they added additional code and tests to ensure this wouldn’t happen going forward.
Some devs learn by trying. Others learn by reading docs. Most seem to learn by reading blog posts that use unnecessary 3rd party packages.
I naïvely assumed that avoiding being paged was motivation enough, but experience has disabused me of that notion. Time after time, “we’ll fix one more thing on our hacky, bespoke bullshit” has won out over “we will use boring, pre-existing solutions.” My favorite example was a team who built a load balancer / health checker for Postgres in NodeJS. Despite causing roughly one incident per month, I was never able to convince anyone that they should abandon their special baby.
I honestly don’t understand how it’s even helpful to put shit like that on your résumé. If I read that in an interview, my immediate question would be “why did you build this instead of using HAProxy / AWS NLB / etc.?”
I have no problem with pandas (though polars is immensely faster, for those cases where it matters), just as I have no problem with numpy; what I dislike is people reaching for them for the most trivial of things that are already solved by stdlib. It’s even more irritating when they cite performance as the necessary reason, but they’re just passing data in a loop, negating nearly all the potential gains.
I'd say there's one more factor here, and it's probably the biggest one for websites and web apps.
Advertisements and tracking.
About 90% of the bloat found on most big company websites comes from these scripts being added all over the place. Ideally removing these would make these sites far more efficient, but the marketing and sales folks probably wouldn't allow it.
Some programmers will write more efficient code. At my $dayjob (one of the big tech companies) we're already planning a major goal next year of optimizing server code to reduce RAM requirements, and this is directly in response to the crunch.
In practice I expect most optimizations will come from "stop doing stupid stuff" and not "use fancy advanced algorithms." But that's a cynical perspective so don't be cynical like me.
Real, there are so many low hanging fruits for optimization but no one has time to do them. And they don’t incentivize spending your time on it either.
If the CEOs are to be believed, then 75% of all new code in Google is AI generated. 46% of GitHub internal code, and roughly 30% across all of Microsoft is AI. Meta expects at least 65%, and snap reported 65% is AI generated.
in aws, some of the core bedrock services have been replaced with the new serving architecture. that thing was written basically with LLMs.
mind you, guy's a distinguished engineer, his team was basically all principals, but you can do it and some of the new teams are copying the style (though with less success, due to lack of technical skill).
> There's nothing more permanent than a temporary fix.
That should be one of those Tech culture “laws.”
I suspect that the dependapocalyse is a significant factor. When every part of an operation has multiple context rebuilds, and resources are not shared across module boundaries, you get inefficient behavior.
But I’m skeptical that there’s a will to rethink that.
I feel that there is a bit of a difference, though, because that’s really a cynical (and probably accurate) observation on the behavior of bureaucracy, and I feel the temporary fix thing is of a “finer granularity,” and applies to basic human nature.
Honestly, after years of seeing this play out, a lot of devs really lack the judgement to know when something is good enough to deliver and will endlessly delay projects to “ do the right thing”
Absolutely. It’s one of the defining characteristics of what makes someone a capable senior in the role IMO.
I have known a lot of extremely talented developers, some with more technical skill than me, that simply failed at their job because they couldn’t come to terms with the fact that their job isn’t to produce the most perfect code possible for the problem.
In my experience, I have only developed internal enterprise software for my entire career. Most of this stuff is gloried CRUD. Above all: Ship early and ship often. You don't get paid more for having less bugs. (Of course, don't ship crap, but you don't need perfection.) Also, often the specs (in my line of business) are unwritten, so you learn more by releasing quickly, then watching (internal) customers use the product and provide feedback.
Totally agree. In these days of fast devs it's common to see PO's excitement reducing deadlines and assumimg a dev can deliver 5 feats in a day instead of trying to stabilize and fix bugs. Sad
I swapped the engine on my lawn mower ~3yr ago because it no longer had any compression and was very hard to start. The new engine has an electric starter. I didn't have time to fabricate a proper battery tray so I ratchet strapped a 2x4 to the gas tank and strapped the battery to that. It stayed that way until last month when I finally had time to weld up a battery tray.
Sometimes when some janky p.o.s. solution works well enough, it truly is good enough.
The key word here is “server”. Optimizing memory server-side directly translates to cost savings for companies. There is a lot less incentive to optimize memory for code that runs on the user’s computer.
> Optimizing memory server-side directly translates to cost savings for companies.
Only if those cost savings exceed the cost of development. Optimisation work is usually done by the most experienced, and hence most expensive engineers. It is also possible that the optimisation efforts will fail to produce meaningful results. In my career, I have seen more optimisation efforts fail than succeed.
That's a clever observation and is very true. Development time tho historically was also very expensive hence push for easy to work with dev stacks such as js
It is typically hard to directly attribute churn though, whereas some massive EC2 instance costing you $30/day is a clear line item where cost savings can be measured easily.
Nah that simply doesn’t happen. Users routinely blame that on the hardware or on the operating system, occasionally rightfully so.
My anecdotal data point: my MacBook neo with 8 gb of ram running mac os is much snappier than my thinkpad x13g1 (ryzen 7 pro, 8c/16t+ 32gb memory) running linux.
Same user (me), same apps, same websites, same data.
Programmers will write more efficient algorithms if their employers tell them to trade time-to-market for hardware cost. Previously, it was trade hardware cost for time-to-market.
"Programmers" don't make this decision, the product owner does.
The classic excuse for industry-wide incompetence. The average programmer today can't write good code even if told it's an explicit priority.
The manager wants the Submit button to submit the form, they rarely care how the programmer does it. It's the programmer that chose to install the 11,000 node_modules, to use React with 3 layers of state management on top with hybrid SSR/CSR and to do Kubernetes because that's what was on Hacker News that day or whatever. And guess what, somehow the Submit button does still not submit the form 10% of the time.
Get rid of the junk and the program will be more efficient AND you'll ship quicker.
I suspect you're imagining something like, just write some vanilla JS and maybe some tasteful but not bloated CSS.
You could do that. Then I'll come along with my old man Win32 skills and write a form with a submit button that sends the data by doing a memcpy into a UDP packet. It will take 300 kilobytes of RAM and start in 0.1 seconds. That'll make it approx 100x more RAM efficient than the baseline you can manage with Chrome, where an empty renderer process takes 23 MB of RAM to achieve nothing and starts so slowly the browser has to cache them in the background.
On the other hand, delivering features your users expect might be a bit harder. Shipping and updating that app will be painful for me, unless I use [plug] https://hydraulic.dev/ to make it easy [/plug], and the styling options are limited to setting solid color backgrounds on things. Things the product manager views as basic, like adding a dark mode, will take a surprising amount of effort. The app is likely to be more crash prone than the web app due to all the manual memory management required. Text zoom won't work. I'll have to write in C or maybe C++ if I'm feeling extravagent.
So there's got to be a balance somewhere. Features do matter.
> The average programmer today can't write good code even if told it's an explicit priority.
But what even is good code?
As an infrastructure guy i see my fellow software engineers endlessly debating and bikeshedding on anything but speed and memory consumption.
I see them arguing about functional vs object oriented, immutable data structures, test driven development, agentic bs, this or that interpreted language… never about reducing memory consumption .
"The boss" is not who says what is good enough. Ultimately it's the customer. In many industries it seems good enough is not very good.
Then there are industries where the customer complains if code is slow. They will actually hire expensive consultants to analyze and benchmark the code. And while the consultants likely are not more talented than inhouse staff, now you have both sides very interested at looking at the problem from engineering perspective.
The language doesn't matter much if you have memory-hungry workloads. Whether it's Rust or C or C#, you can write quite memory efficient code in either.
Most apps don't need much at run time though. There may be a big database somewhere, but the majority of SaaS apps are just some form of CRUD with a clever twist that might change the data occasionally, but doesn't use most of it when you render a page. The user data required for any given page is dwarfed by the memory required to run the language that converts the data to an HTML view.
For example, if you're rendering a user account page that has 100 data fields (name, address, etc), that's a few kilobytes at most. If your code is using Node of PHP you're probably using tens or hundreds of megabytes, possibly gigabytes, to turn that into a stream of HTML to send to the user.
I suspect using Claude to turn all the Node and PHP apps in the world to Rust or Go would massively reduce the necessity for huge datacentres using terabytes of memory.
I have never worked for a company where the engineers choose the technical stack. It’s always the architect, the CTO or the mother company that decides what technology to choose. Could be a German/Dutch cultural thing though.
Depends on a type of company, I work at a mid-sized startup and through lifecycle of this company there were times when we've had architects and there were times when we haven't. Rn we don't have and a lot of decisions is made within teams and we just try to keep communication about what's needed for business tight
Understandable. I worked mainly for 100+ people companies and the tech stack impacts team interoperability, hiring, licenses, life cycle management etcetera.
I have a feeling that the bloated frontend is one of the mayor problems. We should get rid of html, CSS and JavaScript and implement something that could mix all of the above in a single spec and could be implemented using a VM with limited memory/instructions and still render a page one can interact with and use for control of for instance appliances.
Yes, but that doesn't determine the technical stack. It only narrows it down. You could just as well use C, C++, Rust or even Go depending on the device the program needs to run on. The device may have constraints as well but those are technical limitations and still not the responsibility of the product owner.
Platforms are often part of the business requirements.
If you're working on SAP or Salesforce, the language decisions are already made for you. If you're integrating with an existing Electron runtime, then you'll be using something in the JS family, like it or not.
> Choosing a programming language is not a business requirement; it's a technical one.
Technical decisions like this have to take into account a lot of factors outside of just the language itself.
Is the language you want to use easy to hire for? Will we have to pay a premium for engineers with a specialised background in the language? Do all our 3rd party dependencies maintain SDKs for the language? Do libraries that meet various certifications we might need (i.e. FIPS) exist for the language?
Something like Typescript or Java is going to win out over Rust/Erlang/FP-of-your-choice on a number of these criteria.
The programming language can have definite business impacts. It can impact hiring, salary costs (if the skill is rare), ramp-up costs (if it needs to be taught), etc.
Software engineering is an important skill to recruit for. Too many times I see "Java Developer"... Like, do they only know Java and are absolutely incompetent when it comes to something else?
I don't even want to recruit or be recruited with such a title.
Yes, but even then there are people who will ramp up faster.
If the company is using Common Lisp, do you have the 6-12 months to wait for them to ramp up, or do you hire someone who has done Lisp before? That is downstream from the technical decision to use Common Lisp, but it is a huge business impact.
It's definitely possible, but I agree with many other commenters it probably will not happen.
I wrote an encrypted mesh networking library that runs on normal operating systems. A customer asked me if I could make it run on an ESP32 with 520 kiB of RAM. At first this seemed impossible, but it turned out that it was, and not even that hard. While the original library was not memory hungry at all for a desktop CPU, it still wasted space on unnecessarily large buffers. Cutting those out made the library run on an ESP32 while leaving plenty of room for an application.
Also, my first PC was a 200 MHz single-core 32-bit AMD k6 with 32 MiB of RAM. This ran a graphical OS with browsers, word processors, 3D games and so on. Nowadays you can get a CPU with more than that amount of RAM as just built-in cache.
So a good place to start optimizing code would be to actually get a "severely resource constrained" computer and start making your code work on it.
If that happens, we will see it in triple-A games first. If some new titles have significant lower hardware specs than expected.
If buyers can't afford the hardware anymore, the studios need to adjust. It's definitively possible to scale games down a lot. There are a few AAA games that were "dumbed down" for the Switch 1 (Hogwarts, cyberpunk, ...). And that's a really low-spec device.
There are two factors: existing gamers not able to afford upgrading. But also new gamers, that might only be able to afford much lower spec PCs than people who bought 2 years earlier.
Why games? Because there is a clear point where people stop buying games. Minimum hw specs are known before buying.
> If that happens, we will see it in triple-A games first. If some new titles have significant lower hardware specs than expected.
Recently I booted up Insurgency: Sandstorm. With a 5800X and an Intel Arc B580 at 1080p and high graphics, the game runs at around 200 FPS. Meanwhile, pretty much any modern UE5 title (with the exception of Ready or Not and Split Fiction, from what I've seen) runs horribly - the interesting thing is that no matter how much you tweak the .ini files or change the graphics settings you can't get something like STALKER 2 or The Forever Winter or Borderlands 4 to run as well as UE4 with the graphics similar to those old games. Instead you get something that runs at like 10% of the render resolution and still doesn't get 60 FPS (I'm not exaggerating, literally the performance I got in The Forever Winter).
There's no good technical reason for things to be that way (Unity still exists, and the games made in it struggle less) other than the devs or the higher ups choosing higher fidelity but more expensive rendering technologies and using upscaling and framegen not as something that helps laptops or when you need the spare GPU capacity (e.g. encoding a video recording of the game), but rather as something that's supposed to be used to even get to 60 FPS in the first place.
I don't know what needs to change for things to get better.
I also don't see anyone particularly caring about regular software, Electron et al are just too convenient to develop in (having to create per-platform UIs sucks in already-overworked teams).
> I don't know what needs to change for things to get better.
Studios need to start creating custom engines again, for one. We'll get better games with less unsatisfying jank, some of the projects will actually cost less (which is paradoxical to some) and performance is likely to jump significantly. Off-the-shelf engines have as many costs as they have benefits, but like a lot of technology people refuse to look at the choice as a trade-off, and to the extent that they acknowledge it's a trade-off the implicit admission is always that it's a trade-off that the user/player is paying the most for, so it's OK.
If companies start creating custom engines en masse again it will also help solve part of the competency crisis in the industry, because they'll be forced to actually learn and educate people on how things work.
>There's no good technical reason for things to be that way
Of course there is. What people gets presented is look how new graphics is shining. What devs get presented is look how much less manual work you need to get this graphics out of the door. Look at any UE5 presentation aiming at devs. You will be able to see a lot of 'just do this and technology will handle the rest of it'. There is no going back to manually making 3-5 replacements for each and every thing in the game. And the same goes for lights every few meters of a game world.
As a gamedev I don't really care about the regular software. You can see that the main problem for devs is to get paid for it. All kind of schemes with subscriptions and online services and such were tried. People just don't want to pay for the software. The mentality is 'we will get it for pennies on a sale' is the same like with the steam sales. Or even worse people will choose 'free' version with 'promotions' and data collection and whatever else that saves them pennies. Look at 'free to play games' steam category for the example of the horror show.
Oh and I don't think devs are the saints there. You can find a lots of examples that prey on gullible customers or trick people to buy 'digital goods' they don't need or outright bad things with gambling addictions and more.
The only thing consumer can do is to only vote with their wallet and push their representatives to regulate. The stop killing games is an example of the latter. The former is often deemed inefficient but Imho it is the only thing that will separate surviving studios and the shattered ones. As you may see in the press the names and past successes don't save studios from closing their doors now.
Yes, Lumen (and raytracing in general) has a performance overhead. If you don't want that you can skip that feature. Split Fiction and other games choose to do so.
I think certain games like Robocop are awesome on UE5.
> If you don't want that you can skip that feature.
Unfortunately, for the consumer this can also mean skipping some games altogether: for example, I might not be able to play the latest Indiana Jones or Doom game because they refuse to let RT be disabled (unless they get enough pushback, but we can all see where things are heading).
At least there are some (usually indie) games that let you do that, like Incursion: Red River but even with Lumen and other features turned down, the performance is still worse than UE4 games of comparable scene fidelity (not necessarily complexity). I think the industry might have jumped into Nanite and all the adjacent tech way too eagerly.
My comment was of course from the perspective of the game developer. For PC/Windows games it has always been the case that you need the required HW to play the game in a "satisfying" performance.
A lot of RT features makes game development faster (or more efficient) so you won't be able to play the game without them.
No reason to see it in AAA games. They already have to run on Series S, which has ~8 GB usable memory. Consoles are the primary target for any game (if they are not, it is not AAA). So minimum specs remain relatively static through a generation.
I hope we continue local gaming, but my gut tells me we are going to see the opposite. I'd be willing to place a big bet on the new XBox leaning heavily into streaming, like GeForce now. Studios still get to build big, and the consoles get to rent hardware to you now, basically a wet dream for them.
hardware costs must come down or every consumer segment is going to be renting, not owning, everything.
I wouldn’t be surprised if they try but I think the game streaming business model is mostly dead. Stadia was a huge flop, PlayStation has streaming for previous gen games and it sucks, Xbox also has a streaming offering but I haven’t heard anything good about it. It’s a bad user experience and a significant cost to the company providing the streaming.
Are programmers and their use of data structures driving up storage requirements in games though? Or is it just high poly models and high res textures?
Helldivers 2 was in the news a few months ago for "optimizing" and saving over 130gb of disk space required for installation or something to that effect. In actuality, what they did was remove an "optimization" they had implemented without ever once benchmarking and realising it was making things significantly worse. The software development industry is a freaking wreck filled with easy opportunities for improvement if only anyone gave enough of a shit about their consumers to profile their code, ever.
I guess it's not just models and textures. Those should be the easiest to dial down, even optionally with a "low" setting. Maybe making high-res assets an optional download, to reduce game size (ssds are also getting expensive)
If you listen to gaming Youtube then the gaming industry is already in trouble from hardware costs and availability. I'm not sure if they are making a mountain out of a mole hill or not though.
I don't know if I buy it. In the last few years the AAA gaming industry has turned out a lot of bad games, and that probably explains most of the trouble.
> There are two factors: existing gamers not able to afford upgrading. But also new gamers, that might only be able to afford much lower spec PCs than people who bought 2 years earlier.
Spot on.
Now with LLMs and desktop app libraries such as Tauri, there is little excuse in choosing Electron to build memory hungry apps other than laziness.
I don't think we will in the HN snark sense of "this react site or electron app uses way too much memory". Those companies will continue to work in the same way, maybe even less efficiently as people chase modern UIs with extra animations or videos or effects, or with some AI code generation tacking on too many features or tech debt.
In specific sectors I do think we will see more optimization. If you're working on cloud compute or AI training / large scale data processing, there will be a big focus on optimization as prices are very large at that scale and shortages have a bigger effect.
Also in gaming I think the next cycle will be different. Big game studios used to push for the best possible graphics that might require the newest consoles or high end gaming computers, but the next releases might not be as much of an upgrade. The next gen of consoles or graphics cards themselves might be delayed, or be less powerful, or be too expensive and flop, as chip manufacturing companies continue focus on more lucrative markets and leave average consumers behind.
Even today it is possible to use languages and programming techniques to be ultra efficient when it comes to memory. It's not that difficult to use them but the world don't care.
Actual example: I have built same utility using Rust, Zig and Haskell (and Go, humorous writeup[0]). Rust binary is 450kb, Haskell binary 30mb. Zig was unfinished but I constrained memory to 512kb just for fun.
Thus it's not about memory per se but more about convenience. Many applications could be scaled by 1-3 degrees of magnitude in memory if they reused techniques but... no one cares.
4K resolution frame is ~40mb uncompressed. Another 10mb is 80k lines of text. Thus fitting in 50mb for 99.8% of applications should be perfectly doable with today's tech.
If the price increase would be per each next 1mb then maaaaaybeeee. But if it's like 100% over GB then I'm sure it won't have any impact.
Until prices hit the large hyperscalers, I don't think most people are going to make significant changes. You might see a small set of open source projects related to self hosting put in an effort, but in general, I don't think so.
Some big-tech orgs (that have their own hardware) will take costs into account, but they already do that. The "optimization" is more likely to be business-optimizations; "this can be slower if it uses less memory", rather than inventing new stuff.
Note that I am excluding any of the big AI labs. They are definitely going to be working to figure out how to use less memory, but that's primarily not related to the direct cost.
"will they" seems like the least interesting/useful question though. How can we, e.g. raise awareness in users and programmers that this is possible and useful?
I wanna hang out with coders who care, I wanna read articles about caring and how you can achieve more with less code, and I want to see video content that visualizes the sheer insanity of it all. Like those "scale of the universe" videos, except the complexity isn't fascinating, but embarrassing.
Make it uncool, make software bloat a goober thing you people do at most because they "have to", for pointy-haired bosses, or because they're in a rush or under other constraints. Not something that just gets normalized because hey, thinking is hard, caring is hard, so let's all conspire and pretend we're not being deplorable slobs, under the "leadership" of even worse slobs. There is little technical difficulty here, it's mostly social. Ignorance and greed are in cahoots and don't want to get called out, so call them out.
Though I think to start with, you have to not give a shit about the majority, and huddle with people who care and make better things. If the majority comes around, great, if not, still better than standing on the beach, wondering if the ocean will ever spontaneously take this or that shape.
I'll just recognise that I'm old (and a bit grumpy): back in the day, if you didn't write minimally efficient code, it simply wouldn't run or it would be terribly slow.
Young devs have not been exposed to this and they can get away with writing inefficient code most of the time, sometimes all of the time.
And even if there is a RAM shortage, we are still in the Gigabyte age. So I don't think we will go back to cycle and byte counting.
I can't even get some devs to care if their query runs in 3s or 8ms.
> Will programmers write more efficient code during the memory shortage?
If we can insert "some" then Yes.
> use of more advanced algorithms and data structures that use less memory?
I don't think so.
At least at work there is a push to decrease memory usage but the way I've seen it playing out is not using some O(N) data structure instead of O(N lg(N)) per-say but instead replacing `int[]` with `byte[]` or in-lining some fields to remove some indirection costs.
I expect mobile OS and maybe mobile app developers to do so.
Google has already downgraded memory for their upcoming Pixel 11 while at the same time imposing local running models as a first-class feature. Both decreasing the memory pool and increasing the demands on it.
The key is that they own the full stack (hardware and software) and can demand the OS be more efficient, along with perhaps forcing that goal on app developers as well via tightened background limits etc.
> bundling Chromium to make a chat app is the problem.
Precisely. And all that extra resource wastage is completely free! (paid by your customers).
Perhaps if there were any big software companies who were so iconoclastic as to write fast software and avoid wasteful patterns like using Electron, pressure to do better could be felt, but every company that ships software[1] behaves the same so if anyone tries out competition due to performance beefs, they'll have no relief. They'll be forced to blame their hardware and upgrade it.
[1] Only exception of course is some indie developers. I don't know of any companies that have more than about 2 devs who haven't adopted the 'modern' approach, where we only fix performance issues that completely block using the app.
First-party and lovingly-crafted indie apps do use native technologies, and often care about performance, but it feels like everything else uses various bloated cross-platform frameworks.
The fact that nothing on my modern day iPhone feels any faster than my iPhone 4 did, when the current phones are 10x more powerful tells me that developers consistently spend >= 100% of the yearly Moore's Law dividend on framework bloat, spyware, and useless animations. If we could run iOS 6 and its matching apps on modern hardware, and set animation duration to 0 like jailbreaks used to allow, imagine how fast our phones would be!
This isn't where memory goes or real-world speed comes from. For most applications, it's abstractions like React running in electron that hurt performance. There are also richer resources backing parts of apps--higher resolutions, better quality, higher framerates.
Unless there's an actual financial metric to hit: no.
For most people; computers just suck now.
I work in AAA video games, and I'm often told that consoles hold back games. This is true in the most essential sense: for consoles we are forced by the first-parties to optimise our games so that they function on consoles at a reasonable framerate with not hitches.
Those optimisations help PC players too; and they have more hardware headroom so they can crank things up even higher: without those constraints games would be much heavier and would require you to be on a faster moving hardware cycle.
The same is true when I worked in ecommerce; there was a common verbiage which I don't remember verbatim but the spirit of it was "we lose 10% conversion every 100ms" - so we built our systems to do as much as possible within 100ms (including network RTT).
If people actually have target hardware, and a metric that they're pushed towards, it can happen, people can learn how to navigate the abstractions or do better with the abstractions they have... but I think this wont happen, because in the examples above there was an actual cost to things. Conversion rate is money, not being permitted to launch on console is money.
But you know what modern MBAs see as being money? Time to market & developer salaries. If every company has the same mentality: then it doesn't affect conversation in the same way. Those exogenous constraints simply don't exist in the majority of technology today. It's like a collective action problem.
If there was going to be a collective action against this for financial reasons we would have seen it, shipping laptops with 16G of RAM instead of 4G (or 8G) has a really large headline cost in a company of a few thousand people; but those companies never pushed hard on Teams or Slack.
Realistically, the impetus here will come from the platform holders, not the individual programmers.
Apple recently released an 8GB MacBook Neo, which bucks the previous trend of increasing RAM in low-end SKUs, and signals that software needs to be prepared to run in that configuration for a long time to come. I expect we'll see similar moves in smartphones if RAM prices stay elevated.
For this incentive to exist, the app needs to be such an obvious memory hog that users start identifying it as the source of the problem.
Even then, a lot is required for most businesses to prioritize this (presumably) temporary issue at the cost of things like: participation in the AI race, other features, bug fixes, new markets etc.
Heck, sometimes software is so inefficient that it costs developer and tester productivity but a fix is not prioritized for years.
Your response suggests that you're only considering native apps where users can view memory usage.
For cloud apps where the costs are largely hidden from users, the user has no way of doing that analysis. I agree with the second part of what you said, though: I expect businesses to just raise their prices in those cases rather than systematically focus on actual difficult engineering problems.
For cloud apps incentives are aligned already. The cost of memory usage falls on the people who are both paying for it and can control it. It's only really on end user devices where it's a problem, and only really on desktop class machines. iOS and Android were built in a RAM starved environment anyway and aggressively kill any non-foreground process that is using too much memory.
In my experience advanced algorithms and data structures are almost never needed. You need simple data structures and algorithms and understanding of the environment in which you are running (for example see https://handmade.network).
In my company:
- All computers are refurbished and at least 10 years old.
- Cloud deployments use Hetzner or self hosted machines.
- All hardware in general is a bit dodgy. Our main CI/CD setup is on a very unreliable network with varying availability and bandwidth
It can be annoying once in a while but it reflects our customers reality. And it catches a lot of usability and performance bugs that we wouldn't otherwise catch
People did not bother and then the Web made everything worse. We are now so used to layers and layers of abstraction, humongous libraries and frameworks that most do not know anything about how to write "lean" software.
Nothing is going to change in the application/services layer.
I've dumped python for anything that doesn't involve scipy / pytorch in favor of go. So yes, I'm having my llm's output go now which is generally more memory efficient than python.
Python isn't even that bad, I have python desktop apps that use 50mb of memory. More than needed but not 1-2gb realm people complain about with electron stuff.
I would say that in most cases you dont need fancy algorithms and data structures, you just need to stop treating RAM as a rough notebook. Allocating in a loop, not reusing buffers and pointer chasing are a performance killers and are quite easy to avoid before they are introduced to code. Other than that, just be more thoughtful about network and disk usage and nested loops. Its a sum of stupid things that make your program slow.
I might be wearing my tinfoil hat too tight, but I think that market pressure will continue prioritising shipping worse code faster, especially now that with AI it's possible to ship code really fast. The "solution" to expensive hardware will be way less capable hardware and we'll end up with "thin clients" and all compute will happen in centralised "clouds". I hope I'm wrong
We sill probably see an increase in the use of OS-level memory compression tricks instead - things like zwap on Linux, for instance. Because the trend is usually to cure the symptoms, not the cause, as it is generally easier to set up and good enough. Makers who already have invested on memory-careless tech such as Electron won't rewrite; at best they'll just be replaced by better alternatives.
Programmers might write more efficient code if the performance was unacceptable on their own laptops, but even in the not-flush-with-cash companies I've worked all my career, it's been easy for me to always have a dev laptop with twice as much RAM as most consumers have. I'm presently working on a laptop with 64GB, and we don't even use any local AI models. If a PE company is willing to spec dev laptops like this, even in the memory shortage, then I assume the memory pressure will never hit developers.
So, this carefree attitude directly shapes all code that runs client-side (JS + native apps) since the only impact on the company is whatever happens on the dev's laptop. The rest of the impact is "free" since it's paid (in either money or in misery) by customers.
For server side, I also highly doubt it, as being more memory efficient on the server side has always had a benefit to the company who pays the bill. The only things that may change may be the relative cost, but if management comes and says "AWS bill going up, help?" devs will say "OK, we can find ways to save RAM, but the team won't be doing any new features or fixing any customer-facing bugs during that time" and management will say "Okie dokie, we'll just pay the bigger bill then."
One can certainly wish, but I am inclined to believe that RAM use isn’t just about sloppy programmers. I think it is, to a significant degree, about the kinds of problems we solve now that we have more RAM.
And not all exorbitant RAM use is about sloppiness. Sometimes you can trade more RAM use for lower complexity. Bugs and development time were expensive. RAM was not. So sometimes there is calculation rather than sloppiness behind certain types of heavy RAM use.
Backwards thinking programmers might (there is currently plenty of memory efficient software; but it's always missing that feature you really need funny how that works). Forward thinking ones will realize we are heading towards the glut of all gluts and buy 4TB to play around with.
The memory shortage is really for these insane memory requirements for LLMs.
A web browser and the basic mobile app will be fine.
The iPhone 17 Pro has the most RAM and it's only 12GB. Hell the iPhone 16 Pro only had 8 GB. The vast majority of consumer cases don't need it. I doubt Apple and other manufacturers will go beyond that to keep prices down.
In particle physics, processing jobs face a limit of about 2GB/core. This is driven by the realities of "grid computing". The hardware in the computing facilities have approximately 2GB/core and jobs allocate based on number of core. This ratio has been fairly stable for a long time. Some facilities may have a bit more RAM per CPU core but 2GB/core is the general rule of thumb. I hazard a guess that this will not change throughout the (hopefully small number of) years that this memory cost bubble persists. In fact, the increase in cost may lead some facilities to keep older hardware going beyond its EOL/warranty period, prolonging a ratio that may actually be relatively generous compared to today's hardware systems.
As a consequence of this fixed RAM/core ratio, substantial software development effort goes to either making jobs fit in 2GB or if that is not possible then to utilize multithreading. Generally, particle physics processing does not particularly benefit from MT except in this fixed RAM/core situation. Sometimes large memory jobs are needed (inherently or because of bloat that is too costly to improve). When run on the "grid", these jobs must allocate multiple cores just to get "their" memory. If those jobs can use the extra cores, overall throughput does not have to suffer.
That's for conventional software, which still makes up the bulk of the computing. The situation for the growing amount of GPU-accelerated software is different and more varied. One trend can be seen relating to VRAM. Research groups with easy access to big GPUs like A100 write code to fit or exceed the relatively copious VRAM limits of the data-center GPUs, while groups that lack easy access to DC GPUs but have access to more modest "gamer" GPUs write more advanced software that can fit the smaller VRAM. In some cases, they write the software so it can scale the computation, keeping GPU utilization high while staying just under the VRAM limit.
General budget crisis and limited resources in the particle physics field are in part responsible for all of this tailoring of the software to fit the hardware. If better funded, particle physicists could spend more time doing physics and less time squeezing last drops of processing power.
I remember reading somewhere about an HPC "rule of thumb" that was like 1GB RAM/1GHz of processing is about the right amount for most applications.. Don't recall where that came from or what the exact reasoning was. That kind of aligns with 2GB/core.. Was that a thing?
Maybe it was a thing from before clock speeds saturated and Moore's law mutated into being satisfied by ever increasing core count? It could have been useful when spec'ing hardware with the goal of running multi-threaded jobs that scale both their throughput and RAM requirements linearly with number of threads. That would make it sort of a continuous version of the more discrete GB/core rule of thumb. However, such linearly-scaled MT jobs are a subset of all MT jobs. And, ST jobs are not covered. A 2GB ST job on a 1GB / 1GHz machine will again need two cores, wasting one. When run on a 5GB/5GHz machine the job needs only its one core but must waste 3GB.
In particle physics, as more of the code is being GPU-accelerated, there is now another integer ratio to worry about optimizing: CPU core per GPU device. Across the landscape, some jobs have zero GPU acceleration, others may need 100 cores to keep a GPU busy, or only 1 core. Yet others can tune their CPU/GPU ratio to optimize throughput given what hardware ratio a given facility provides. Only a fraction of the software in the ecosystem takes up this challenge.
Most physicist pretending to be software developers or vice versa who are involved in the field do not consider any of these computing realities. At some level, that's natural and excusable. It's hard enough to develop the simulation and reconstruction and analysis algorithms. Simultaneously optimizing their implementation for throughput on a given hardware assumption is even harder. Harder still is to do that optimization over the variety of hardware assumptions. There are only a few cases where this holistic thinking has driven the design of the software.
It's endlessly fascinating to me how long it's taking for GPUs to be adopted for this kind of workload. I remember all the excitement around the GPGPU era, OpenCL, and eventually CUDA. That was like 15yr ago! Yes, GPUs can do a fantastic amount of computing. But it's really hard to make them do it efficiently. I think maybe the implicit assumption at the time was that something would come along that would make it easier. Despite continuous advances over the last decade+ it's still really hard.
I feel like we're about to learn a similar lesson with generative AI. Things don't always get easier/better/faster.
A related question "Do current programmers know how to write programs with low memory requirements ?".
When I started out, the mini computers were 16 bit and there was a limit to program size. You could do a lot within those limits, but once in a great while I did exceed the limits and the compile (if lucky) would fail or the program would dump. That was well before GUIs.
I believe the GUI portion of a program are the largest use of memory, so I do not even know if people today can survive without GUIs :)
Considering how many greenfield projects are reaching for Electron, and how few of them are moving off of it, I would say not.
Until Electron based projects have viable competitors that aren’t using Electron, this nightmare will continue. There is absolutely no justification for consuming 300Mb to 4Gb of RAM when a native app doing the exact same thing typically uses 5% to 0.05% as much memory.
No, even at these high memory prices it's cheaper to produce code as fast as possible than to spend the time to optimize it for efficiency. It has always been the case that hardware improves at a faster pace than software. So what will happen is that we will get tech improvements in hardware that will reduce its price faster than we can write software to fully take advantage of the hardware. The current bottle neck that's causing the spike in memory prices will subside relatively soon so we'll be in better shape before we know it.
Will we? I don’t think new capacity will come online for several years and at the current rate there’s not a lot of evidence that the new capacity won’t simply be scooped up by the big data centers like they are now. At the very least we’re in for a rough 4 years at least
you are assuming this is a new problem to be 'solved'; folks working on the embedded systems, and network infra headless systems have been wiping this surface clean for many decades;
stepping outside of garbage collection, and managed runtime systems could teach a lot; there was a book written 20 or so years ago;
I'd hope so. Not just because of the memory shortage, but because of the speed at which AI can help write code. Most high-level languages came about in order to speed up development, at the cost of performance and resource consumption. It's time to revisit some of these applications and see if we can use less resources to accomplish the same task. My work laptop with Teams and 2 Edge tabs open uses roughly 11GB of memory, which is insane.
The only way to make them to write efficient code is to force developers to do development and testing of the software on the weak machine.
At my current job we have Windows virtual machines with 4 old Xeon cores, running at 2.4Ghz and 16Gb of RAM, no GPU. Such config will force them to write efficient UI.
If memory shortages were not caused by AI then may be (but still unlikely). In the current situation even cautious in the past companies are switching to “move fast and break things” mode to not fall behind vibe coding competitors. When the velocity is the top priority there is no time fo efficiency.
Yes. Let's hope bloated frameworks like react, angular and vue with their dreaded hydration and ssr approaches will be replaced with pure clientside applications with stateless servers with small data apis only. That alone will reduce zeptibytes of memory requirements in the world.
They might, but the final outcome of that depends on whether the tokenmaxxing rust-using zero-user startups are using more memory in ci/cd than the users of efficiently written successful apps are using in production.
You don't save memory with code, you save it with architecture, platform decisions, and feedback loops.
Feedback loops are the important bit. If you want to reduce your service's memory footprint, don't at the code look at the memory profile and monitoring. You will find something like "oh shit 30% of our RAM is used by these buffers that we could basically eliminate if we tweak the flush frequency".
If you automate/regularise those investigations you will get an efficient service.
Same is true of every other performance metric, and reliability. It comes from your engineering processes (alerts, qualification, prod experimentation) not "write better code".
But I’m hopefully optimistic that we’ll see a renewed emphasis on speed and responsiveness, since users do notice that despite most products ignoring it.
it wont happen, we gonna get uber lazy and stop using brain. new generations already scored less points in every single intellectual tests then generations before them. we will need even more memory in future cos of bad code, just look at windows 11, its awful
I certainly hope so, it's cheaper than ever to write native code, but if sub-trillion dollar valuated companies like OpenAI have done the math and still use electron for the codex app, one has to ponder what was considered.
If the producers see a long term demand for memory they will meet the challenge and produce enough to bring prices down.
Economics will invariably alleviate the memory crunch. It just takes long and requires a huge upfront CapEx.
They have been burned in the past and are hesitant to over invest, worried that the bubble might burst.
I expect high prices to stick around for a while, but I would be surprised if this was permanent.
Which means to me, that price pressure probably won't be the driving force for writing more memory efficient software.
For those who want, I expect AI to make it easier to do that, assuming it's done right, i.e. not vibe coding it.
If you have a subscription to The Economist, I recommend listening to this Money Talks podcast. They talk about the shortage and the economics behind it.
Two Chinese chip makers—CXMT, the country’s top DRAM producer, and Yangtze Memory Technologies, which focuses on NAND storage—are growing fast and want to expand their global clientele. China is the closest thing to a quick fix for the chip shortage, but the solution is at best partial.
Yangtze Memory is building three new factories in China that would more than double its current capacity by the end of 2027, people familiar with the plans said. Meanwhile CXMT is seeking to raise $4 billion in an initial public offering in Shanghai, and it is building new factories. It said its revenue rose by more than 700% year-over-year in the first quarter of 2026, though it acknowledged that its products still trail those of the three industry leaders.”
I doubt many of the newer generation ever even tried. Maybe they had a course at uni where they did some C or Assembly, but that's probably the extend of it. So no, I don't think so lol.
Let me get this straight. We have a memory shortage due to AI slop which is not really efficient and to solve that problem we need to stop the AI slop and hand write the code.
Of course not. Why would they? The software nowadays is mostly written for people who already own computers with RAM already installed. Yeah, they probably won't upgrade for the next couple of years, so what?
Besides, have you heard about "virtual memory" and "swapping"? Nowadays, SSDs (and especially NVMe) are quite fast, so thrashing is much less of an issue.
Thankfully, AI allows you to write tightly-coupled code (the kind Uncle Bob and Martin Fowler warned you not to write!) which is usually more efficient.
You could be a senior dev with over a decades experience at this stage doing nothing but chucking react slop over the fence, performance may have never once come up as a consideration in that time.
> Will programmers write more efficient code during the memory shortage?
Yes. No. Yes.
I've worked in gamedev, helping ship code that ran on consoles. Nice fixed hardware targets. You OOM, you crash. We crashed a lot, and cut and saved and optimized and explicitly invoked the garbage collector twice on level transitions, because a single full scripting language GC doesn't work when finalizers must run to deref C++ objects to unroot script objects, and committed other horrific hacks.
The memory shortage may eventually impact fixed targets like this. Or the minspec publishers will swallow for fuzzier targets like "PC". But it takes awhile for new targets to roll out, and for newly bought PCs to make a significant dent on total percentage of PC ownership. Steam Machine's about to release with 16+8GB and while price and market saturation may be affected by the memory shortage, I'd be suprised if the actual spec changed.
> Maybe there will even be more interest in the invention and use of more advanced algorithms
Not for typical gamedev IMO. There the focus will be more on "reduce the amount of content loaded in memory simultaniously". That means less detail, smaller scale, or less variation. Going from 4096x4096 to 2048x2048 textures quarters your texture memory usage. The surface of meshes also has some square density nonsense going on. Basic animation tends to scale with bone count and keyframes, which are more linear, although shape keys are more per-vertex nonsense.
And of course, reusing the same mesh or texture multiple times doesn't use more memory, just more memory bandwidth.
Audio is more a factor of "how many sound effects (and variants) do we need preloaded just in case there's suddenly an event that triggers them".
These are the big ticket items for memory use and advanced algorithms don't help much. Rather, the algorithms help stretch whatever amount of memory you do have to provide the best amount of quality you can, and the small constant shift in total memory availability doesn't change the calculus for how important that is very much (which depending on the game ranges from "unimportant, everything fits in memory easily" to "critical, we're doing open world streaming and we've got terrabytes of raw data already, 16 vs 64GB of memory doesn't change that much")
> and data structures that use less memory?
Some bit packing type stuff comes up for smaller logical data structures in gamedev, and that can be useful for saving memory bandwidth, but I'm skeptical of how critical it is for total memory usage outside of the occasional Factorio.
Machine telemetry data (logs, metrics, traces) are shipped around as highly redundant utf-8 strings. I'm sure there are plenty of other examples of 2+ orders of magnitude improvements that aren't even low hanging fruit, they're basically groundfall. But picking them up may nonetheless require quite a bit of effort, and a major reevaluation of corporate values. Maybe the RAM crunch will be sufficient incentive? Idk.
EDIT: It's also possible that the era of hypergrowth might end. Most of the world's addressable eyeballs are already being monetized. There's no new coal seam to mine. If tech becomes more about doing the same with less, and less about explosively growing at all costs, we'll probably see more efficient systems. And fewer people building them. I think this kind of larger systemic change would be more likely to drive efficiency improvements than the (probably more temporary) RAM crunch.
Depends entirely on how competitive / adversarial the market segment is. And there are wild nonlinearities, just as you care a lot whether or not something fits in an 8-way set associative L1d but once you're too big or bank conflicted to make it the cost model drops sharply until you're about to spill the L2.
The hackers doing the drone software in Ukraine will go to enormous lengths to get something onto Jetson Orin, but once it needs Thor? New cost model.
I think what the parent might be asking is whether the cost of DRAM will be passed along to the most powerless actor in the system, and that depends on whether it's a real competition (war, HFT) or a pillow fight between frenemies (consumer Internet, too big to fail AI lab).
Us liberals have this quaint idea that good referees make capitalism an adversarial contest instead of a rolodex contest, but that idea is out of fashion at the moment.
I don't see the underlying economic dynamics of the relevance of substitution costs driving the way we do things going away. And substitution costs are all about limitations.
Abundance and limitations are a bit of ying/yang phenomena in terms of driving things, you don't have one without the other.
Igor Stravinsky: "Constraint drives creativity"
(I also don't see Amdahl's Law --which is fundamentally about limitations -- going away any time soon.)
I do agree that there are compounding abundancies present.
Nuclear-powered hyperscale data centers in your neighborhood disagree. Not saying it's a good thing, but like it or not, if you ask "what generally drives how we do things", that's probably it.
I don't believe so do for two reasons:
- everyone assumes their program / website is the only thing running at the machine at a given time, and dev machines are always more powerful than user machines
- it's not really lack of advanced data structures and algorithms that result in the bloat most of the time but the fact that programs and websites are delivered by large teams, there are dozens of submodules that are often loaded even when not needed, and doing it properly is hard to architect to without getting into big complexity and gnarly bugs waiting to happen when someone from other team modifies something and does not know full picture. So it's cheaper to just keep things the way they are to reduce complexity of architecture and fragility.
It's a bit more subtle than bad assumptions.
The main place RAM usage is going to get optimized is on the server side, because the client's RAM is a tragedy of the commons. If you're reducing RAM usage while your competitor adds features then the extra RAM saved by your app will just be silently allocated to theirs, the device won't feel any different and the user will prefer your competitor. There is little incentive to optimize RAM usage on the client side because it only helps other companies, so nobody does it - except (ironically) browser devs, who tend to assume they have first dibs on all the RAM of the device.
If you really wanted people to care about it OS devs would need to surface memory usage of apps visibly in a way ordinary users can understand and translate to customer feedback forms, which is difficult.
If you're reducing RAM usage while your competitor...
This is true so long as client-side (desktop, mobile) memory management does not penalise high memory use.
I'm already taking the approach of killing off my largest browser processes regularly, and need to look at more targeted ways of managing memory. I'd really like to see the parent browser process as a lightweight manager over subprocesses such that it can persist (rather than leaking multiple GB of RAM over the course of days), to the point my entire user session falls over with stunning regularity.
I have a shell script (currently triggered manually, hopefully subject to further refinement) which kills off the ten top browser processes. I'll often run that in a shell loop of 10--20 iterations. It barely keeps things manageable, and system hangs/reboots are still far more common than I'd like.
The way to change behaviours is to change costs. This is where OS devs have a choice before them, and application and remote service / SaaS devs and project managers might eventually start feeling the pain.
One reason I favour HN over numerous other options is that the site doesn't absolutely pig out my browser session(s).
And that said, if anyone has tips on both revealing and managing memory usage in Firefox, I'm quite receptive.
> The main place RAM usage is going to get optimized is on the server side
Agree, but it's going to be a long, hard, potentially ultimately unsuccessful uphill slog. I think the main obstacle is basically 2 decades of inertia. Approximately everyone believes that server side software needs to scale horizontally. So we optimize systems for this property--I can make it work better by just throwing more computers at it. This was a lot more important ca. 2004 (MapReduce) than it is ca. 2026. For resiliency and redundancy, how many nodes does your service actually need? If you're running more than that number, do you have some kind of justification as to why? This is the mindset we need to try to move towards, but it's very different from how we currently do it.
EDIT: Another good question to ask, which we don't do enough: "does it really need to be a separate service?" Using data in RAM that's already been allocated is probably better than allocating more and shipping data over the network...
FWIW I work part time on projects that are all about reducing RAM usage server side! RAM has been a big expense in the cloud for a long time. AI makes the situation critical but there's a lot of work done already. Consider that functions-as-a-service are basically all about shutting down idle servers to reclaim their RAM.
FaaS are really interesting, because the tradeoffs seem "jagged" (to use a word I learned recently). Like, IIUC this is more or less what's happening when a cloud function is invoked:
1. Some event triggers the function (HTTP request hits load balancer or whatever)
2. A VM is loaded from NVMe (possibly on another computer, and transferred over the network) into RAM
3. That VM boots up
4. The function code runs
5. The VM is terminated
Naively, this probably takes a lot more RAM (not to mention all the other computing resources) than to just have another HTTP handler sitting idle on some computer somewhere.
So this is only a reasonable choice if doing this intensive computation for a short amount of time, and using a large amount of resources for that short amount of time, is somehow better than doing a much smaller amount (maybe none at all) of computing over a longer amount of time. It's kind of hard to tell what the actual conditions are that merit one solution over the other. The other layer is the cloud pricing model, but that's a whole other can of worms..
I have yet to encounter a system that didn't have at least some computers (or cloud instances) that always need to be running. Those computers are almost always a bit overprovisioned (not using 100% of their CPU or RAM or IO all the time). So it has always seemed to me that instead of running a cloud function, it would be cheaper in terms of compute resources to execute the code from step 4 above on one of those machines.
Obviously we have cloud functions for a reason, people like them and find them useful. But is there ever a regime where they're optimal?
EDIT: I guess I've implicitly assumed the code in step 4 is doing a small amount of work. Maybe there's a goldilocks zone of work-per-invocation where this model is more optimal? But then of course there's always the standard executor pool model, and that way you don't have to spin up a VM per task invocation...
> the fact that programs and websites are delivered by large teams, there are dozens of submodules that are often loaded even when not needed
Precisely this. We had an incident once where a CSV had a postal code field be interpreted as an integer by pandas, which of course results in stripping any leading 0s. After looking at what the code needed to do, I asked why they were using pandas in the first place, as it was literally just “read the CSV as-is into a list.” Guess what Python’s stdlib csv module doesn't do? Type inference.
Instead of replacing the unnecessary pandas import (which brings along a fairly heavy transitive chain) with stdlib, they added additional code and tests to ensure this wouldn’t happen going forward.
Some devs learn by trying. Others learn by reading docs. Most seem to learn by reading blog posts that use unnecessary 3rd party packages.
It's called resume-driven-development. You can't add stdlib into your resume while you can pandas.
If there are no guardrails, loose quality control and nobody cares about performance - why should they replace current pandas with stdlib?
I naïvely assumed that avoiding being paged was motivation enough, but experience has disabused me of that notion. Time after time, “we’ll fix one more thing on our hacky, bespoke bullshit” has won out over “we will use boring, pre-existing solutions.” My favorite example was a team who built a load balancer / health checker for Postgres in NodeJS. Despite causing roughly one incident per month, I was never able to convince anyone that they should abandon their special baby.
I honestly don’t understand how it’s even helpful to put shit like that on your résumé. If I read that in an interview, my immediate question would be “why did you build this instead of using HAProxy / AWS NLB / etc.?”
Reason number 500 why I hate pandas with a passion. Just had basically the exact same thing happen at work
I have no problem with pandas (though polars is immensely faster, for those cases where it matters), just as I have no problem with numpy; what I dislike is people reaching for them for the most trivial of things that are already solved by stdlib. It’s even more irritating when they cite performance as the necessary reason, but they’re just passing data in a loop, negating nearly all the potential gains.
I'd say there's one more factor here, and it's probably the biggest one for websites and web apps.
Advertisements and tracking.
About 90% of the bloat found on most big company websites comes from these scripts being added all over the place. Ideally removing these would make these sites far more efficient, but the marketing and sales folks probably wouldn't allow it.
Some programmers will write more efficient code. At my $dayjob (one of the big tech companies) we're already planning a major goal next year of optimizing server code to reduce RAM requirements, and this is directly in response to the crunch.
In practice I expect most optimizations will come from "stop doing stupid stuff" and not "use fancy advanced algorithms." But that's a cynical perspective so don't be cynical like me.
Real, there are so many low hanging fruits for optimization but no one has time to do them. And they don’t incentivize spending your time on it either.
Exactly. Customer's RAM is free to the developer.
Especially when LLMs are used to generate most of the code anyways in bigcorps
Is there a single example of a successful LLM project apart from Claude Code?
If the CEOs are to be believed, then 75% of all new code in Google is AI generated. 46% of GitHub internal code, and roughly 30% across all of Microsoft is AI. Meta expects at least 65%, and snap reported 65% is AI generated.
Its how software is built now in these palces.
Unfortunately doesn’t answer the question “successful LLM project”.
From what I’ve seen of GitHub and AWS this year the answer is no. That’s despite me being bullish on LLMs and finding them highly productive.
https://blog.joemag.dev/2025/10/the-new-calculus-of-ai-based...?
in aws, some of the core bedrock services have been replaced with the new serving architecture. that thing was written basically with LLMs.
mind you, guy's a distinguished engineer, his team was basically all principals, but you can do it and some of the new teams are copying the style (though with less success, due to lack of technical skill).
Amazon Bedrock is their LLM serving system, so it's basically in the same class as Claude Code: AI infrastructure.
99% of my new writing is generated by scigen, but 0% of my successful writing.
Given the uhhh, quality and issues GitHub and Microslop have been exhibiting recently, that’s probably not a great indicator.
Github was down so much, I was surprised that they didn't use Copilot to fix their issues
Bun, Ghostty
Migration projects probably won't be the best fit here
An existing project has a well defined code base, test cases etc
If llms aren't able to migrate a good project then they wouldn't be of any use for general purpose programming
“Stop doing stupid stuff” is usually the biggest performance gain in commercial development.
We do stupid stuff as a stopgap to meet a deadline and then stupid stuff stays until it starts being a problem.
There's nothing more permanent than a temporary fix. If deadlines are causing those stopgaps, the aggressive deadlines are the root problem.
> There's nothing more permanent than a temporary fix.
That should be one of those Tech culture “laws.”
I suspect that the dependapocalyse is a significant factor. When every part of an operation has multiple context rebuilds, and resources are not shared across module boundaries, you get inefficient behavior.
But I’m skeptical that there’s a will to rethink that.
> That should be one of those Tech culture “laws.”
We already have something:
"Nothing is so permanent as a temporary government program."
Milton Friedman, Tyranny of the Status Quo
Thanks for that.
I feel that there is a bit of a difference, though, because that’s really a cynical (and probably accurate) observation on the behavior of bureaucracy, and I feel the temporary fix thing is of a “finer granularity,” and applies to basic human nature.
In my experience, many of those deadlines are commonly the only reason the company continues to exist as well.
The root of the problem is much more deeply ingrained in our economic system.
Honestly, after years of seeing this play out, a lot of devs really lack the judgement to know when something is good enough to deliver and will endlessly delay projects to “ do the right thing”
Absolutely. It’s one of the defining characteristics of what makes someone a capable senior in the role IMO.
I have known a lot of extremely talented developers, some with more technical skill than me, that simply failed at their job because they couldn’t come to terms with the fact that their job isn’t to produce the most perfect code possible for the problem.
In my experience, I have only developed internal enterprise software for my entire career. Most of this stuff is gloried CRUD. Above all: Ship early and ship often. You don't get paid more for having less bugs. (Of course, don't ship crap, but you don't need perfection.) Also, often the specs (in my line of business) are unwritten, so you learn more by releasing quickly, then watching (internal) customers use the product and provide feedback.
Totally agree. In these days of fast devs it's common to see PO's excitement reducing deadlines and assumimg a dev can deliver 5 feats in a day instead of trying to stabilize and fix bugs. Sad
No deadline, no product.
Shipping is very important, sometimes more important than what you ship :)
I swapped the engine on my lawn mower ~3yr ago because it no longer had any compression and was very hard to start. The new engine has an electric starter. I didn't have time to fabricate a proper battery tray so I ratchet strapped a 2x4 to the gas tank and strapped the battery to that. It stayed that way until last month when I finally had time to weld up a battery tray.
Sometimes when some janky p.o.s. solution works well enough, it truly is good enough.
The key word here is “server”. Optimizing memory server-side directly translates to cost savings for companies. There is a lot less incentive to optimize memory for code that runs on the user’s computer.
That's a clever observation and is very true. Development time tho historically was also very expensive hence push for easy to work with dev stacks such as js
There's plenty of incentive if it causes your users to churn.
It is typically hard to directly attribute churn though, whereas some massive EC2 instance costing you $30/day is a clear line item where cost savings can be measured easily.
Nah that simply doesn’t happen. Users routinely blame that on the hardware or on the operating system, occasionally rightfully so.
My anecdotal data point: my MacBook neo with 8 gb of ram running mac os is much snappier than my thinkpad x13g1 (ryzen 7 pro, 8c/16t+ 32gb memory) running linux.
Same user (me), same apps, same websites, same data.
I don’t really blame the apps.
even a lot of the fancy algorithms are ways to not do something you dont need to do, it's rooting out waste all the way down.
Programmers will write more efficient algorithms if their employers tell them to trade time-to-market for hardware cost. Previously, it was trade hardware cost for time-to-market.
"Programmers" don't make this decision, the product owner does.
The classic excuse for industry-wide incompetence. The average programmer today can't write good code even if told it's an explicit priority.
The manager wants the Submit button to submit the form, they rarely care how the programmer does it. It's the programmer that chose to install the 11,000 node_modules, to use React with 3 layers of state management on top with hybrid SSR/CSR and to do Kubernetes because that's what was on Hacker News that day or whatever. And guess what, somehow the Submit button does still not submit the form 10% of the time.
Get rid of the junk and the program will be more efficient AND you'll ship quicker.
How much "junk" do you want to get rid of?
I suspect you're imagining something like, just write some vanilla JS and maybe some tasteful but not bloated CSS.
You could do that. Then I'll come along with my old man Win32 skills and write a form with a submit button that sends the data by doing a memcpy into a UDP packet. It will take 300 kilobytes of RAM and start in 0.1 seconds. That'll make it approx 100x more RAM efficient than the baseline you can manage with Chrome, where an empty renderer process takes 23 MB of RAM to achieve nothing and starts so slowly the browser has to cache them in the background.
On the other hand, delivering features your users expect might be a bit harder. Shipping and updating that app will be painful for me, unless I use [plug] https://hydraulic.dev/ to make it easy [/plug], and the styling options are limited to setting solid color backgrounds on things. Things the product manager views as basic, like adding a dark mode, will take a surprising amount of effort. The app is likely to be more crash prone than the web app due to all the manual memory management required. Text zoom won't work. I'll have to write in C or maybe C++ if I'm feeling extravagent.
So there's got to be a balance somewhere. Features do matter.
> The average programmer today can't write good code even if told it's an explicit priority.
But what even is good code?
As an infrastructure guy i see my fellow software engineers endlessly debating and bikeshedding on anything but speed and memory consumption.
I see them arguing about functional vs object oriented, immutable data structures, test driven development, agentic bs, this or that interpreted language… never about reducing memory consumption .
What is "good code"?
If you ask your boss, it will most likely be whatever spaghetti code which ensures the contract gets signed on time.
The boss doesn't care if the developer needs 10000 libraries for the submit button.
"The boss" is not who says what is good enough. Ultimately it's the customer. In many industries it seems good enough is not very good.
Then there are industries where the customer complains if code is slow. They will actually hire expensive consultants to analyze and benchmark the code. And while the consultants likely are not more talented than inhouse staff, now you have both sides very interested at looking at the problem from engineering perspective.
In this case "good" includes performance.
I disagree. Engineers choose the technical stack based on the specs.
With LLMs, it's faster to ship even in a more verbose language like Go or Rust.
The language doesn't matter much if you have memory-hungry workloads. Whether it's Rust or C or C#, you can write quite memory efficient code in either.
Most apps don't need much at run time though. There may be a big database somewhere, but the majority of SaaS apps are just some form of CRUD with a clever twist that might change the data occasionally, but doesn't use most of it when you render a page. The user data required for any given page is dwarfed by the memory required to run the language that converts the data to an HTML view.
For example, if you're rendering a user account page that has 100 data fields (name, address, etc), that's a few kilobytes at most. If your code is using Node of PHP you're probably using tens or hundreds of megabytes, possibly gigabytes, to turn that into a stream of HTML to send to the user.
I suspect using Claude to turn all the Node and PHP apps in the world to Rust or Go would massively reduce the necessity for huge datacentres using terabytes of memory.
And Java? Language matters.
I don't have any metrics in mimd but with GraalVM it's probably a much closer race. It's made by Oracle though...
Except that most of the time a workload is made memory-hungry by terrible technical decisions ("self-describing" text data encodings come to mind).
I have never worked for a company where the engineers choose the technical stack. It’s always the architect, the CTO or the mother company that decides what technology to choose. Could be a German/Dutch cultural thing though.
Depends on a type of company, I work at a mid-sized startup and through lifecycle of this company there were times when we've had architects and there were times when we haven't. Rn we don't have and a lot of decisions is made within teams and we just try to keep communication about what's needed for business tight
Understandable. I worked mainly for 100+ people companies and the tech stack impacts team interoperability, hiring, licenses, life cycle management etcetera.
I have a feeling that the bloated frontend is one of the mayor problems. We should get rid of html, CSS and JavaScript and implement something that could mix all of the above in a single spec and could be implemented using a VM with limited memory/instructions and still render a page one can interact with and use for control of for instance appliances.
The spec is the important part, though. If memory limitations are part of the spec, you're not going to choose a stack that will be too wasteful.
Yes, but that doesn't determine the technical stack. It only narrows it down. You could just as well use C, C++, Rust or even Go depending on the device the program needs to run on. The device may have constraints as well but those are technical limitations and still not the responsibility of the product owner.
Who determines the specs?
Specs are business requirements. Choosing a programming language is not a business requirement; it's a technical one.
Platforms are often part of the business requirements.
If you're working on SAP or Salesforce, the language decisions are already made for you. If you're integrating with an existing Electron runtime, then you'll be using something in the JS family, like it or not.
> Choosing a programming language is not a business requirement; it's a technical one.
Technical decisions like this have to take into account a lot of factors outside of just the language itself.
Is the language you want to use easy to hire for? Will we have to pay a premium for engineers with a specialised background in the language? Do all our 3rd party dependencies maintain SDKs for the language? Do libraries that meet various certifications we might need (i.e. FIPS) exist for the language?
Something like Typescript or Java is going to win out over Rust/Erlang/FP-of-your-choice on a number of these criteria.
> Choosing a programming language is not a business requirement; it's a technical one.
Not solely. The business will have reasons to stay on a mainstream language, for example because
- it offers better guarantees for hiring maintainers in the future
- it has a higher likelihood that security issues will be fixed rapidly for free
- LLMs are better at maintaining code written in it
The programming language can have definite business impacts. It can impact hiring, salary costs (if the skill is rare), ramp-up costs (if it needs to be taught), etc.
Even bus-factor comes into it.
Software engineering is an important skill to recruit for. Too many times I see "Java Developer"... Like, do they only know Java and are absolutely incompetent when it comes to something else?
I don't even want to recruit or be recruited with such a title.
Yes, but even then there are people who will ramp up faster.
If the company is using Common Lisp, do you have the 6-12 months to wait for them to ramp up, or do you hire someone who has done Lisp before? That is downstream from the technical decision to use Common Lisp, but it is a huge business impact.
> trade time-to-market for hardware cost
Enh. I think this only exists for some programmers, who can't write good code fast.
Whatever you're already able to do, you can do it better with more time.
source?
Ehm. I would assume your definition of writing good code fast is not what the majority of enterprise developers agrees with.
Fast, correct, maintainable. Pick two.
It's definitely possible, but I agree with many other commenters it probably will not happen.
I wrote an encrypted mesh networking library that runs on normal operating systems. A customer asked me if I could make it run on an ESP32 with 520 kiB of RAM. At first this seemed impossible, but it turned out that it was, and not even that hard. While the original library was not memory hungry at all for a desktop CPU, it still wasted space on unnecessarily large buffers. Cutting those out made the library run on an ESP32 while leaving plenty of room for an application.
Also, my first PC was a 200 MHz single-core 32-bit AMD k6 with 32 MiB of RAM. This ran a graphical OS with browsers, word processors, 3D games and so on. Nowadays you can get a CPU with more than that amount of RAM as just built-in cache.
So a good place to start optimizing code would be to actually get a "severely resource constrained" computer and start making your code work on it.
If that happens, we will see it in triple-A games first. If some new titles have significant lower hardware specs than expected.
If buyers can't afford the hardware anymore, the studios need to adjust. It's definitively possible to scale games down a lot. There are a few AAA games that were "dumbed down" for the Switch 1 (Hogwarts, cyberpunk, ...). And that's a really low-spec device.
There are two factors: existing gamers not able to afford upgrading. But also new gamers, that might only be able to afford much lower spec PCs than people who bought 2 years earlier.
Why games? Because there is a clear point where people stop buying games. Minimum hw specs are known before buying.
> If that happens, we will see it in triple-A games first. If some new titles have significant lower hardware specs than expected.
Recently I booted up Insurgency: Sandstorm. With a 5800X and an Intel Arc B580 at 1080p and high graphics, the game runs at around 200 FPS. Meanwhile, pretty much any modern UE5 title (with the exception of Ready or Not and Split Fiction, from what I've seen) runs horribly - the interesting thing is that no matter how much you tweak the .ini files or change the graphics settings you can't get something like STALKER 2 or The Forever Winter or Borderlands 4 to run as well as UE4 with the graphics similar to those old games. Instead you get something that runs at like 10% of the render resolution and still doesn't get 60 FPS (I'm not exaggerating, literally the performance I got in The Forever Winter).
There's no good technical reason for things to be that way (Unity still exists, and the games made in it struggle less) other than the devs or the higher ups choosing higher fidelity but more expensive rendering technologies and using upscaling and framegen not as something that helps laptops or when you need the spare GPU capacity (e.g. encoding a video recording of the game), but rather as something that's supposed to be used to even get to 60 FPS in the first place.
I don't know what needs to change for things to get better.
I also don't see anyone particularly caring about regular software, Electron et al are just too convenient to develop in (having to create per-platform UIs sucks in already-overworked teams).
> I don't know what needs to change for things to get better.
Studios need to start creating custom engines again, for one. We'll get better games with less unsatisfying jank, some of the projects will actually cost less (which is paradoxical to some) and performance is likely to jump significantly. Off-the-shelf engines have as many costs as they have benefits, but like a lot of technology people refuse to look at the choice as a trade-off, and to the extent that they acknowledge it's a trade-off the implicit admission is always that it's a trade-off that the user/player is paying the most for, so it's OK.
If companies start creating custom engines en masse again it will also help solve part of the competency crisis in the industry, because they'll be forced to actually learn and educate people on how things work.
Do you actually believe in what you wrote above?
Game studios should choose CryEngine/Decima again over UE5
>There's no good technical reason for things to be that way
Of course there is. What people gets presented is look how new graphics is shining. What devs get presented is look how much less manual work you need to get this graphics out of the door. Look at any UE5 presentation aiming at devs. You will be able to see a lot of 'just do this and technology will handle the rest of it'. There is no going back to manually making 3-5 replacements for each and every thing in the game. And the same goes for lights every few meters of a game world.
As a gamedev I don't really care about the regular software. You can see that the main problem for devs is to get paid for it. All kind of schemes with subscriptions and online services and such were tried. People just don't want to pay for the software. The mentality is 'we will get it for pennies on a sale' is the same like with the steam sales. Or even worse people will choose 'free' version with 'promotions' and data collection and whatever else that saves them pennies. Look at 'free to play games' steam category for the example of the horror show.
Oh and I don't think devs are the saints there. You can find a lots of examples that prey on gullible customers or trick people to buy 'digital goods' they don't need or outright bad things with gambling addictions and more.
The only thing consumer can do is to only vote with their wallet and push their representatives to regulate. The stop killing games is an example of the latter. The former is often deemed inefficient but Imho it is the only thing that will separate surviving studios and the shattered ones. As you may see in the press the names and past successes don't save studios from closing their doors now.
Yes, Lumen (and raytracing in general) has a performance overhead. If you don't want that you can skip that feature. Split Fiction and other games choose to do so.
I think certain games like Robocop are awesome on UE5.
> If you don't want that you can skip that feature.
Unfortunately, for the consumer this can also mean skipping some games altogether: for example, I might not be able to play the latest Indiana Jones or Doom game because they refuse to let RT be disabled (unless they get enough pushback, but we can all see where things are heading).
At least there are some (usually indie) games that let you do that, like Incursion: Red River but even with Lumen and other features turned down, the performance is still worse than UE4 games of comparable scene fidelity (not necessarily complexity). I think the industry might have jumped into Nanite and all the adjacent tech way too eagerly.
My comment was of course from the perspective of the game developer. For PC/Windows games it has always been the case that you need the required HW to play the game in a "satisfying" performance.
A lot of RT features makes game development faster (or more efficient) so you won't be able to play the game without them.
No reason to see it in AAA games. They already have to run on Series S, which has ~8 GB usable memory. Consoles are the primary target for any game (if they are not, it is not AAA). So minimum specs remain relatively static through a generation.
I hope we continue local gaming, but my gut tells me we are going to see the opposite. I'd be willing to place a big bet on the new XBox leaning heavily into streaming, like GeForce now. Studios still get to build big, and the consoles get to rent hardware to you now, basically a wet dream for them.
hardware costs must come down or every consumer segment is going to be renting, not owning, everything.
I wouldn’t be surprised if they try but I think the game streaming business model is mostly dead. Stadia was a huge flop, PlayStation has streaming for previous gen games and it sucks, Xbox also has a streaming offering but I haven’t heard anything good about it. It’s a bad user experience and a significant cost to the company providing the streaming.
> hardware costs must come down or every consumer segment is going to be renting, not owning, everything.
Is this not exactly what companies want
Are programmers and their use of data structures driving up storage requirements in games though? Or is it just high poly models and high res textures?
Helldivers 2 was in the news a few months ago for "optimizing" and saving over 130gb of disk space required for installation or something to that effect. In actuality, what they did was remove an "optimization" they had implemented without ever once benchmarking and realising it was making things significantly worse. The software development industry is a freaking wreck filled with easy opportunities for improvement if only anyone gave enough of a shit about their consumers to profile their code, ever.
I guess it's not just models and textures. Those should be the easiest to dial down, even optionally with a "low" setting. Maybe making high-res assets an optional download, to reduce game size (ssds are also getting expensive)
If you listen to gaming Youtube then the gaming industry is already in trouble from hardware costs and availability. I'm not sure if they are making a mountain out of a mole hill or not though.
I don't know if I buy it. In the last few years the AAA gaming industry has turned out a lot of bad games, and that probably explains most of the trouble.
Games are designed for consoles which aren't going to change in the near term.
> There are two factors: existing gamers not able to afford upgrading. But also new gamers, that might only be able to afford much lower spec PCs than people who bought 2 years earlier.
Spot on.
Now with LLMs and desktop app libraries such as Tauri, there is little excuse in choosing Electron to build memory hungry apps other than laziness.
Tauri sucks on macOS and especially Linux, because the native browsers are a huge issue. Tauri/Windows uses a recent Chromium engine, which is fine.
That's memory efficient assets, not memory efficient code. The latter is already optimized for the former.
Switch was notorious for having a few Cloud streamed-games that don't run on the actual hardware.
which ones were those? I want to check them out
The Switch 1 Kingdom Hearts game are like that.
I don't think we will in the HN snark sense of "this react site or electron app uses way too much memory". Those companies will continue to work in the same way, maybe even less efficiently as people chase modern UIs with extra animations or videos or effects, or with some AI code generation tacking on too many features or tech debt.
In specific sectors I do think we will see more optimization. If you're working on cloud compute or AI training / large scale data processing, there will be a big focus on optimization as prices are very large at that scale and shortages have a bigger effect.
Also in gaming I think the next cycle will be different. Big game studios used to push for the best possible graphics that might require the newest consoles or high end gaming computers, but the next releases might not be as much of an upgrade. The next gen of consoles or graphics cards themselves might be delayed, or be less powerful, or be too expensive and flop, as chip manufacturing companies continue focus on more lucrative markets and leave average consumers behind.
No.
Even today it is possible to use languages and programming techniques to be ultra efficient when it comes to memory. It's not that difficult to use them but the world don't care.
Actual example: I have built same utility using Rust, Zig and Haskell (and Go, humorous writeup[0]). Rust binary is 450kb, Haskell binary 30mb. Zig was unfinished but I constrained memory to 512kb just for fun.
Thus it's not about memory per se but more about convenience. Many applications could be scaled by 1-3 degrees of magnitude in memory if they reused techniques but... no one cares.
4K resolution frame is ~40mb uncompressed. Another 10mb is 80k lines of text. Thus fitting in 50mb for 99.8% of applications should be perfectly doable with today's tech.
If the price increase would be per each next 1mb then maaaaaybeeee. But if it's like 100% over GB then I'm sure it won't have any impact.
[0]: https://xlii.space/eng/the-four-language-waltz-a-tale-of-all...
You can drain all the system RAM with a tiny binary, so I am not sure you used the right metric.
Until prices hit the large hyperscalers, I don't think most people are going to make significant changes. You might see a small set of open source projects related to self hosting put in an effort, but in general, I don't think so.
Some big-tech orgs (that have their own hardware) will take costs into account, but they already do that. The "optimization" is more likely to be business-optimizations; "this can be slower if it uses less memory", rather than inventing new stuff.
Note that I am excluding any of the big AI labs. They are definitely going to be working to figure out how to use less memory, but that's primarily not related to the direct cost.
The new generation of Graviton on AWS ships with half the RAM per core in the standard family.
"will they" seems like the least interesting/useful question though. How can we, e.g. raise awareness in users and programmers that this is possible and useful?
I wanna hang out with coders who care, I wanna read articles about caring and how you can achieve more with less code, and I want to see video content that visualizes the sheer insanity of it all. Like those "scale of the universe" videos, except the complexity isn't fascinating, but embarrassing.
Make it uncool, make software bloat a goober thing you people do at most because they "have to", for pointy-haired bosses, or because they're in a rush or under other constraints. Not something that just gets normalized because hey, thinking is hard, caring is hard, so let's all conspire and pretend we're not being deplorable slobs, under the "leadership" of even worse slobs. There is little technical difficulty here, it's mostly social. Ignorance and greed are in cahoots and don't want to get called out, so call them out.
Though I think to start with, you have to not give a shit about the majority, and huddle with people who care and make better things. If the majority comes around, great, if not, still better than standing on the beach, wondering if the ocean will ever spontaneously take this or that shape.
> I wanna hang out with coders who care, I wanna read articles about caring and how you can achieve more with less code
This very much reminds me of an expression coined by Loris Cro (VP of Community at Zig Foundation): "Create software you can love".
Looks like it's even got a website these days: https://softwareyoucan.love/
I'll just recognise that I'm old (and a bit grumpy): back in the day, if you didn't write minimally efficient code, it simply wouldn't run or it would be terribly slow.
Young devs have not been exposed to this and they can get away with writing inefficient code most of the time, sometimes all of the time.
And even if there is a RAM shortage, we are still in the Gigabyte age. So I don't think we will go back to cycle and byte counting.
I can't even get some devs to care if their query runs in 3s or 8ms.
> Will programmers write more efficient code during the memory shortage?
If we can insert "some" then Yes.
> use of more advanced algorithms and data structures that use less memory?
I don't think so.
At least at work there is a push to decrease memory usage but the way I've seen it playing out is not using some O(N) data structure instead of O(N lg(N)) per-say but instead replacing `int[]` with `byte[]` or in-lining some fields to remove some indirection costs.
It is a really simple matter of incentives.
If your backlog is full of feature requests you will add features.
If your backlog is full of tasks to reduce memory usage, speed up areas etc., then that is what you will do.
Most programmers will have no choice whatsoever.
I expect mobile OS and maybe mobile app developers to do so.
Google has already downgraded memory for their upcoming Pixel 11 while at the same time imposing local running models as a first-class feature. Both decreasing the memory pool and increasing the demands on it.
The key is that they own the full stack (hardware and software) and can demand the OS be more efficient, along with perhaps forcing that goal on app developers as well via tightened background limits etc.
Google has done multiple Android memory reduction sprints over the years.
The problem is that things go quickly in the other direction between these sprints.
Algorithms and data structures aren't the problem, bundling Chromium to make a chat app is the problem.
I think Rust's rise in popularity will probably lead to some benefits.
Games will probably get more efficient but they're easier to scale down to the memory that's available.
> bundling Chromium to make a chat app is the problem.
Precisely. And all that extra resource wastage is completely free! (paid by your customers).
Perhaps if there were any big software companies who were so iconoclastic as to write fast software and avoid wasteful patterns like using Electron, pressure to do better could be felt, but every company that ships software[1] behaves the same so if anyone tries out competition due to performance beefs, they'll have no relief. They'll be forced to blame their hardware and upgrade it.
[1] Only exception of course is some indie developers. I don't know of any companies that have more than about 2 devs who haven't adopted the 'modern' approach, where we only fix performance issues that completely block using the app.
You're forgetting about Apple and that entire ecosystem.
Android, too. Not much Electron to be found there. Both Android and iOS were heavily optimized for low memory environments back at the start.
First-party and lovingly-crafted indie apps do use native technologies, and often care about performance, but it feels like everything else uses various bloated cross-platform frameworks.
The fact that nothing on my modern day iPhone feels any faster than my iPhone 4 did, when the current phones are 10x more powerful tells me that developers consistently spend >= 100% of the yearly Moore's Law dividend on framework bloat, spyware, and useless animations. If we could run iOS 6 and its matching apps on modern hardware, and set animation duration to 0 like jailbreaks used to allow, imagine how fast our phones would be!
Unfortunately shipping a Webview is also common trend in Rust applications.
> advanced algorithms and data structures
This isn't where memory goes or real-world speed comes from. For most applications, it's abstractions like React running in electron that hurt performance. There are also richer resources backing parts of apps--higher resolutions, better quality, higher framerates.
I was thinking about this recently. If you discount web/electron bloat, actually the memory bloat of software isn't hugely terrible.
I still often notice that servers on Linux use <1GB of RAM even with relatively high use. I don't think that's really changed massively in 20 years.
Unless there's an actual financial metric to hit: no.
For most people; computers just suck now.
I work in AAA video games, and I'm often told that consoles hold back games. This is true in the most essential sense: for consoles we are forced by the first-parties to optimise our games so that they function on consoles at a reasonable framerate with not hitches.
Those optimisations help PC players too; and they have more hardware headroom so they can crank things up even higher: without those constraints games would be much heavier and would require you to be on a faster moving hardware cycle.
The same is true when I worked in ecommerce; there was a common verbiage which I don't remember verbatim but the spirit of it was "we lose 10% conversion every 100ms" - so we built our systems to do as much as possible within 100ms (including network RTT).
If people actually have target hardware, and a metric that they're pushed towards, it can happen, people can learn how to navigate the abstractions or do better with the abstractions they have... but I think this wont happen, because in the examples above there was an actual cost to things. Conversion rate is money, not being permitted to launch on console is money.
But you know what modern MBAs see as being money? Time to market & developer salaries. If every company has the same mentality: then it doesn't affect conversation in the same way. Those exogenous constraints simply don't exist in the majority of technology today. It's like a collective action problem.
If there was going to be a collective action against this for financial reasons we would have seen it, shipping laptops with 16G of RAM instead of 4G (or 8G) has a really large headline cost in a company of a few thousand people; but those companies never pushed hard on Teams or Slack.
Realistically, the impetus here will come from the platform holders, not the individual programmers.
Apple recently released an 8GB MacBook Neo, which bucks the previous trend of increasing RAM in low-end SKUs, and signals that software needs to be prepared to run in that configuration for a long time to come. I expect we'll see similar moves in smartphones if RAM prices stay elevated.
There's hope for the extinction of Electron based apps.
They aren’t going away. They are an obvious answer to Microsoft GUI development being in the wilderness for 20 years.
Java has been right there all along like the awkward best friend in a romcom.
It’s funny to me that a lot of the initial dismissal of Swing was “it isn’t native widgets”. Now that’s seen as a positive.
And Qt. They even made QML with literal reactive JavaScript.
If only there were other options available, cross platform even,...
For this incentive to exist, the app needs to be such an obvious memory hog that users start identifying it as the source of the problem.
Even then, a lot is required for most businesses to prioritize this (presumably) temporary issue at the cost of things like: participation in the AI race, other features, bug fixes, new markets etc.
Heck, sometimes software is so inefficient that it costs developer and tester productivity but a fix is not prioritized for years.
Your response suggests that you're only considering native apps where users can view memory usage.
For cloud apps where the costs are largely hidden from users, the user has no way of doing that analysis. I agree with the second part of what you said, though: I expect businesses to just raise their prices in those cases rather than systematically focus on actual difficult engineering problems.
For cloud apps incentives are aligned already. The cost of memory usage falls on the people who are both paying for it and can control it. It's only really on end user devices where it's a problem, and only really on desktop class machines. iOS and Android were built in a RAM starved environment anyway and aggressively kill any non-foreground process that is using too much memory.
In my experience advanced algorithms and data structures are almost never needed. You need simple data structures and algorithms and understanding of the environment in which you are running (for example see https://handmade.network).
I don't think many will.
But I think they should. Not only for the practical reason, but because it leads to better software in my opinion
Limitations foster creativity. Abundance kills innovation.
In my company: - All computers are refurbished and at least 10 years old. - Cloud deployments use Hetzner or self hosted machines. - All hardware in general is a bit dodgy. Our main CI/CD setup is on a very unreliable network with varying availability and bandwidth
It can be annoying once in a while but it reflects our customers reality. And it catches a lot of usability and performance bugs that we wouldn't otherwise catch
I can only recommend it
You must be joking.
Niklaus Wirth wrote his A Plea for Lean Software in 1995. Pdf at https://people.inf.ethz.ch/wirth/Articles/LeanSoftware.pdf
People did not bother and then the Web made everything worse. We are now so used to layers and layers of abstraction, humongous libraries and frameworks that most do not know anything about how to write "lean" software.
Nothing is going to change in the application/services layer.
Unless users complain it’s not going to happen. Somehow SPA (Single-page application) consume memory as much as operating system.
I've dumped python for anything that doesn't involve scipy / pytorch in favor of go. So yes, I'm having my llm's output go now which is generally more memory efficient than python.
Python isn't even that bad, I have python desktop apps that use 50mb of memory. More than needed but not 1-2gb realm people complain about with electron stuff.
I would say that in most cases you dont need fancy algorithms and data structures, you just need to stop treating RAM as a rough notebook. Allocating in a loop, not reusing buffers and pointer chasing are a performance killers and are quite easy to avoid before they are introduced to code. Other than that, just be more thoughtful about network and disk usage and nested loops. Its a sum of stupid things that make your program slow.
8Gb laptops are about the only tech still selling. Exec's better think long and hard about that.
I might be wearing my tinfoil hat too tight, but I think that market pressure will continue prioritising shipping worse code faster, especially now that with AI it's possible to ship code really fast. The "solution" to expensive hardware will be way less capable hardware and we'll end up with "thin clients" and all compute will happen in centralised "clouds". I hope I'm wrong
We sill probably see an increase in the use of OS-level memory compression tricks instead - things like zwap on Linux, for instance. Because the trend is usually to cure the symptoms, not the cause, as it is generally easier to set up and good enough. Makers who already have invested on memory-careless tech such as Electron won't rewrite; at best they'll just be replaced by better alternatives.
Programmers might write more efficient code if the performance was unacceptable on their own laptops, but even in the not-flush-with-cash companies I've worked all my career, it's been easy for me to always have a dev laptop with twice as much RAM as most consumers have. I'm presently working on a laptop with 64GB, and we don't even use any local AI models. If a PE company is willing to spec dev laptops like this, even in the memory shortage, then I assume the memory pressure will never hit developers.
So, this carefree attitude directly shapes all code that runs client-side (JS + native apps) since the only impact on the company is whatever happens on the dev's laptop. The rest of the impact is "free" since it's paid (in either money or in misery) by customers.
For server side, I also highly doubt it, as being more memory efficient on the server side has always had a benefit to the company who pays the bill. The only things that may change may be the relative cost, but if management comes and says "AWS bill going up, help?" devs will say "OK, we can find ways to save RAM, but the team won't be doing any new features or fixing any customer-facing bugs during that time" and management will say "Okie dokie, we'll just pay the bigger bill then."
That’ll be a minor part of it.
The whole Electron “ship a browser for each app” ideology will die first.
It's unlikely. It means rewriting all these Electron apps using something more performant, which is pretty costly.
Yeah it won’t mean rewrites. It’ll just die as a starting point.
One can certainly wish, but I am inclined to believe that RAM use isn’t just about sloppy programmers. I think it is, to a significant degree, about the kinds of problems we solve now that we have more RAM.
And not all exorbitant RAM use is about sloppiness. Sometimes you can trade more RAM use for lower complexity. Bugs and development time were expensive. RAM was not. So sometimes there is calculation rather than sloppiness behind certain types of heavy RAM use.
No. They won't.
Most games are written for the 3% who can afford a luxury gaming PC. That's how the market is working for a while now.
Most games are developed for game consoles, not high-end PCs.
Most AAA games maybe. All the unity games that run sh*t on anything except a high end PC aren't.
However that's more or less unity fault
My bigger hope (for apple ecosystem) is that macbook neo forces apple to optimize. Devs don't have that scale.
Backwards thinking programmers might (there is currently plenty of memory efficient software; but it's always missing that feature you really need funny how that works). Forward thinking ones will realize we are heading towards the glut of all gluts and buy 4TB to play around with.
The memory shortage is really for these insane memory requirements for LLMs.
A web browser and the basic mobile app will be fine.
The iPhone 17 Pro has the most RAM and it's only 12GB. Hell the iPhone 16 Pro only had 8 GB. The vast majority of consumer cases don't need it. I doubt Apple and other manufacturers will go beyond that to keep prices down.
In particle physics, processing jobs face a limit of about 2GB/core. This is driven by the realities of "grid computing". The hardware in the computing facilities have approximately 2GB/core and jobs allocate based on number of core. This ratio has been fairly stable for a long time. Some facilities may have a bit more RAM per CPU core but 2GB/core is the general rule of thumb. I hazard a guess that this will not change throughout the (hopefully small number of) years that this memory cost bubble persists. In fact, the increase in cost may lead some facilities to keep older hardware going beyond its EOL/warranty period, prolonging a ratio that may actually be relatively generous compared to today's hardware systems.
As a consequence of this fixed RAM/core ratio, substantial software development effort goes to either making jobs fit in 2GB or if that is not possible then to utilize multithreading. Generally, particle physics processing does not particularly benefit from MT except in this fixed RAM/core situation. Sometimes large memory jobs are needed (inherently or because of bloat that is too costly to improve). When run on the "grid", these jobs must allocate multiple cores just to get "their" memory. If those jobs can use the extra cores, overall throughput does not have to suffer.
That's for conventional software, which still makes up the bulk of the computing. The situation for the growing amount of GPU-accelerated software is different and more varied. One trend can be seen relating to VRAM. Research groups with easy access to big GPUs like A100 write code to fit or exceed the relatively copious VRAM limits of the data-center GPUs, while groups that lack easy access to DC GPUs but have access to more modest "gamer" GPUs write more advanced software that can fit the smaller VRAM. In some cases, they write the software so it can scale the computation, keeping GPU utilization high while staying just under the VRAM limit.
General budget crisis and limited resources in the particle physics field are in part responsible for all of this tailoring of the software to fit the hardware. If better funded, particle physicists could spend more time doing physics and less time squeezing last drops of processing power.
I remember reading somewhere about an HPC "rule of thumb" that was like 1GB RAM/1GHz of processing is about the right amount for most applications.. Don't recall where that came from or what the exact reasoning was. That kind of aligns with 2GB/core.. Was that a thing?
Maybe it was a thing from before clock speeds saturated and Moore's law mutated into being satisfied by ever increasing core count? It could have been useful when spec'ing hardware with the goal of running multi-threaded jobs that scale both their throughput and RAM requirements linearly with number of threads. That would make it sort of a continuous version of the more discrete GB/core rule of thumb. However, such linearly-scaled MT jobs are a subset of all MT jobs. And, ST jobs are not covered. A 2GB ST job on a 1GB / 1GHz machine will again need two cores, wasting one. When run on a 5GB/5GHz machine the job needs only its one core but must waste 3GB.
In particle physics, as more of the code is being GPU-accelerated, there is now another integer ratio to worry about optimizing: CPU core per GPU device. Across the landscape, some jobs have zero GPU acceleration, others may need 100 cores to keep a GPU busy, or only 1 core. Yet others can tune their CPU/GPU ratio to optimize throughput given what hardware ratio a given facility provides. Only a fraction of the software in the ecosystem takes up this challenge.
Most physicist pretending to be software developers or vice versa who are involved in the field do not consider any of these computing realities. At some level, that's natural and excusable. It's hard enough to develop the simulation and reconstruction and analysis algorithms. Simultaneously optimizing their implementation for throughput on a given hardware assumption is even harder. Harder still is to do that optimization over the variety of hardware assumptions. There are only a few cases where this holistic thinking has driven the design of the software.
It's endlessly fascinating to me how long it's taking for GPUs to be adopted for this kind of workload. I remember all the excitement around the GPGPU era, OpenCL, and eventually CUDA. That was like 15yr ago! Yes, GPUs can do a fantastic amount of computing. But it's really hard to make them do it efficiently. I think maybe the implicit assumption at the time was that something would come along that would make it easier. Despite continuous advances over the last decade+ it's still really hard.
I feel like we're about to learn a similar lesson with generative AI. Things don't always get easier/better/faster.
A related question "Do current programmers know how to write programs with low memory requirements ?".
When I started out, the mini computers were 16 bit and there was a limit to program size. You could do a lot within those limits, but once in a great while I did exceed the limits and the compile (if lucky) would fail or the program would dump. That was well before GUIs.
I believe the GUI portion of a program are the largest use of memory, so I do not even know if people today can survive without GUIs :)
It's not THAT much of a memory shortage.
It's not a memory shortage like the world had run out of gas for cars.
It's not like we suddenly only have 1MB of RAM to fit stuff into.
The memory shortage means stuff costs more that's all.
Considering how many greenfield projects are reaching for Electron, and how few of them are moving off of it, I would say not.
Until Electron based projects have viable competitors that aren’t using Electron, this nightmare will continue. There is absolutely no justification for consuming 300Mb to 4Gb of RAM when a native app doing the exact same thing typically uses 5% to 0.05% as much memory.
No, even at these high memory prices it's cheaper to produce code as fast as possible than to spend the time to optimize it for efficiency. It has always been the case that hardware improves at a faster pace than software. So what will happen is that we will get tech improvements in hardware that will reduce its price faster than we can write software to fully take advantage of the hardware. The current bottle neck that's causing the spike in memory prices will subside relatively soon so we'll be in better shape before we know it.
Will we? I don’t think new capacity will come online for several years and at the current rate there’s not a lot of evidence that the new capacity won’t simply be scooped up by the big data centers like they are now. At the very least we’re in for a rough 4 years at least
It's going to be years before memory prices go down to what the were last year. At least two or three years.
you are assuming this is a new problem to be 'solved'; folks working on the embedded systems, and network infra headless systems have been wiping this surface clean for many decades;
stepping outside of garbage collection, and managed runtime systems could teach a lot; there was a book written 20 or so years ago;
https://smallmemory.charlesweir.com/
I'd hope so. Not just because of the memory shortage, but because of the speed at which AI can help write code. Most high-level languages came about in order to speed up development, at the cost of performance and resource consumption. It's time to revisit some of these applications and see if we can use less resources to accomplish the same task. My work laptop with Teams and 2 Edge tabs open uses roughly 11GB of memory, which is insane.
The only way to make them to write efficient code is to force developers to do development and testing of the software on the weak machine.
At my current job we have Windows virtual machines with 4 old Xeon cores, running at 2.4Ghz and 16Gb of RAM, no GPU. Such config will force them to write efficient UI.
It's not like we're stuck back with 640kb... At the very least you probably have 8-16GB of RAM still...
If memory shortages were not caused by AI then may be (but still unlikely). In the current situation even cautious in the past companies are switching to “move fast and break things” mode to not fall behind vibe coding competitors. When the velocity is the top priority there is no time fo efficiency.
No. Customers will pay more across all markets.
what do you mean?
They're answering the question posed in the article: No, programmers won't write more efficient code.
They're suggesting that instead, consumers will just be forced to pay more for inefficient SaaS products being run on more expensive infrastructure.
Yes. Let's hope bloated frameworks like react, angular and vue with their dreaded hydration and ssr approaches will be replaced with pure clientside applications with stateless servers with small data apis only. That alone will reduce zeptibytes of memory requirements in the world.
Are you joking? If anything, they'll use even more memory by shoving 8B LLMs in every single app.
Only if people start buying computers with less memory, if they just buy fewer computers it doesn’t seem worhwhile.
They might, but the final outcome of that depends on whether the tokenmaxxing rust-using zero-user startups are using more memory in ci/cd than the users of efficiently written successful apps are using in production.
It could certainly be used as a way to sell killing some technical debt for performance improvements to management, for anyone struggling to.
“The new MacBook only has 8 gigs of sheep - we need to go resource-lean!!1!”
You don't save memory with code, you save it with architecture, platform decisions, and feedback loops.
Feedback loops are the important bit. If you want to reduce your service's memory footprint, don't at the code look at the memory profile and monitoring. You will find something like "oh shit 30% of our RAM is used by these buffers that we could basically eliminate if we tweak the flush frequency".
If you automate/regularise those investigations you will get an efficient service.
Same is true of every other performance metric, and reliability. It comes from your engineering processes (alerts, qualification, prod experimentation) not "write better code".
Will you stop using docker to deploy a simple application? No? Didn't think so.
No, because most of your memory usage comes before a line of your code runs. That's where the efforts will be focused.
With the age of AISlop why you expecting better quality?
Lad, modern day "programmers" don't even know what memory is. You'll be lucky to find any "software engineer" who can even tell you what a pointer is.
I can refer you to some documentation on the topic. ;)
I'm pretty sure the person who you are responding to already knows and does not need your documentation.
But most 'programmers' are just Python programmers and not real programmers.
1. It was a joke about pointers.
2. Cut out the macho gatekeeping nonsense around what makes a "real" programmer. It's tiresome.
Will they? I don't know. Should they? Yes. If AI is so great, we should use it to optimize. Rewrite all the bloat into lean efficient systems...
Memory? Doubt it.
But I’m hopefully optimistic that we’ll see a renewed emphasis on speed and responsiveness, since users do notice that despite most products ignoring it.
Will users choose more efficient programs during the memory shortage
Or is user choice illusory, nonexistant
*nonexistent
Are there promotion metrics tied to app performance? Or are they tied to deliverables?
Unless that changes we won't see any spike in optimization
No. The cost of one programmer’s hour of work compared to the increase in price of RAM is not very big. One is a variable cost one is fixed.
it wont happen, we gonna get uber lazy and stop using brain. new generations already scored less points in every single intellectual tests then generations before them. we will need even more memory in future cos of bad code, just look at windows 11, its awful
I don't see the trend reversing, but if we're lucky, perhaps a freeze. Won't get more efficient but may not get worse.
AI (like alcohol) is the cause-of and solution-to all our problems.
Computer: Rewrite this python code in Go. Make it memory efficient.
What's causing the memory shortage is also directly writing less efficient code, so no.
Depends. I can certainly offer to rewrite my old code that contributed to the memory shortage, for a price.
A few will write low level code that will make all code behave more memory efficiently.
I certainly hope so, it's cheaper than ever to write native code, but if sub-trillion dollar valuated companies like OpenAI have done the math and still use electron for the codex app, one has to ponder what was considered.
Not unless you get promoted for writing more efficient code.
If the producers see a long term demand for memory they will meet the challenge and produce enough to bring prices down.
Economics will invariably alleviate the memory crunch. It just takes long and requires a huge upfront CapEx.
They have been burned in the past and are hesitant to over invest, worried that the bubble might burst.
I expect high prices to stick around for a while, but I would be surprised if this was permanent.
Which means to me, that price pressure probably won't be the driving force for writing more memory efficient software.
For those who want, I expect AI to make it easier to do that, assuming it's done right, i.e. not vibe coding it.
If you have a subscription to The Economist, I recommend listening to this Money Talks podcast. They talk about the shortage and the economics behind it.
Can anything stop South Korea’s bull run?
https://www.economist.com/podcasts/2026/05/21/can-anything-s...
From a paywalled article in the WSJ:
“ The China card
Two Chinese chip makers—CXMT, the country’s top DRAM producer, and Yangtze Memory Technologies, which focuses on NAND storage—are growing fast and want to expand their global clientele. China is the closest thing to a quick fix for the chip shortage, but the solution is at best partial.
Yangtze Memory is building three new factories in China that would more than double its current capacity by the end of 2027, people familiar with the plans said. Meanwhile CXMT is seeking to raise $4 billion in an initial public offering in Shanghai, and it is building new factories. It said its revenue rose by more than 700% year-over-year in the first quarter of 2026, though it acknowledged that its products still trail those of the three industry leaders.”
Gift link: https://www.wsj.com/tech/why-the-memory-crunch-is-almost-imp...
I doubt many of the newer generation ever even tried. Maybe they had a course at uni where they did some C or Assembly, but that's probably the extend of it. So no, I don't think so lol.
Can they still write that code?
Probably not, clarity still triumphs
unless something niche, no. It's not like we are going back to cpp pointers and memory management.
> will programmers write
Who’s going to tell them?
Well, they're asking on Hacker News, so they're probably asking the broader collective, not just (presumptuously) themselves.
I think the implication is programmers aren't going to be the ones writing code anymore.
currently porting code from Go to Rust primarily motivated by memory efficiency gains
Let me get this straight. We have a memory shortage due to AI slop which is not really efficient and to solve that problem we need to stop the AI slop and hand write the code.
I think they are writing shorter code for to token limits...
(Just refactored an app to do this. 60k lines to 20k)
Of course not. Why would they? The software nowadays is mostly written for people who already own computers with RAM already installed. Yeah, they probably won't upgrade for the next couple of years, so what?
Besides, have you heard about "virtual memory" and "swapping"? Nowadays, SSDs (and especially NVMe) are quite fast, so thrashing is much less of an issue.
those that did before still will.
Those that didn't still won't
One could hope for.
Thankfully, AI allows you to write tightly-coupled code (the kind Uncle Bob and Martin Fowler warned you not to write!) which is usually more efficient.
A lot simply wouldn't be able to.
You could be a senior dev with over a decades experience at this stage doing nothing but chucking react slop over the fence, performance may have never once come up as a consideration in that time.
> Will programmers write more efficient code during the memory shortage?
Yes. No. Yes.
I've worked in gamedev, helping ship code that ran on consoles. Nice fixed hardware targets. You OOM, you crash. We crashed a lot, and cut and saved and optimized and explicitly invoked the garbage collector twice on level transitions, because a single full scripting language GC doesn't work when finalizers must run to deref C++ objects to unroot script objects, and committed other horrific hacks.
The memory shortage may eventually impact fixed targets like this. Or the minspec publishers will swallow for fuzzier targets like "PC". But it takes awhile for new targets to roll out, and for newly bought PCs to make a significant dent on total percentage of PC ownership. Steam Machine's about to release with 16+8GB and while price and market saturation may be affected by the memory shortage, I'd be suprised if the actual spec changed.
> Maybe there will even be more interest in the invention and use of more advanced algorithms
Not for typical gamedev IMO. There the focus will be more on "reduce the amount of content loaded in memory simultaniously". That means less detail, smaller scale, or less variation. Going from 4096x4096 to 2048x2048 textures quarters your texture memory usage. The surface of meshes also has some square density nonsense going on. Basic animation tends to scale with bone count and keyframes, which are more linear, although shape keys are more per-vertex nonsense.
And of course, reusing the same mesh or texture multiple times doesn't use more memory, just more memory bandwidth.
Audio is more a factor of "how many sound effects (and variants) do we need preloaded just in case there's suddenly an event that triggers them".
These are the big ticket items for memory use and advanced algorithms don't help much. Rather, the algorithms help stretch whatever amount of memory you do have to provide the best amount of quality you can, and the small constant shift in total memory availability doesn't change the calculus for how important that is very much (which depending on the game ranges from "unimportant, everything fits in memory easily" to "critical, we're doing open world streaming and we've got terrabytes of raw data already, 16 vs 64GB of memory doesn't change that much")
> and data structures that use less memory?
Some bit packing type stuff comes up for smaller logical data structures in gamedev, and that can be useful for saving memory bandwidth, but I'm skeptical of how critical it is for total memory usage outside of the occasional Factorio.
Machine telemetry data (logs, metrics, traces) are shipped around as highly redundant utf-8 strings. I'm sure there are plenty of other examples of 2+ orders of magnitude improvements that aren't even low hanging fruit, they're basically groundfall. But picking them up may nonetheless require quite a bit of effort, and a major reevaluation of corporate values. Maybe the RAM crunch will be sufficient incentive? Idk.
EDIT: It's also possible that the era of hypergrowth might end. Most of the world's addressable eyeballs are already being monetized. There's no new coal seam to mine. If tech becomes more about doing the same with less, and less about explosively growing at all costs, we'll probably see more efficient systems. And fewer people building them. I think this kind of larger systemic change would be more likely to drive efficiency improvements than the (probably more temporary) RAM crunch.
No
No
no
claude code and friends will make it much easier to rewrite python/js/$memory-hungry code in rust.
and make memory hungry rust code with unsafe everywhere. Way to go!
None of my LLM created rust code has unsafe, or unwrap and must pass clippy checks..
Depends entirely on how competitive / adversarial the market segment is. And there are wild nonlinearities, just as you care a lot whether or not something fits in an 8-way set associative L1d but once you're too big or bank conflicted to make it the cost model drops sharply until you're about to spill the L2.
The hackers doing the drone software in Ukraine will go to enormous lengths to get something onto Jetson Orin, but once it needs Thor? New cost model.
I think what the parent might be asking is whether the cost of DRAM will be passed along to the most powerless actor in the system, and that depends on whether it's a real competition (war, HFT) or a pillow fight between frenemies (consumer Internet, too big to fail AI lab).
Us liberals have this quaint idea that good referees make capitalism an adversarial contest instead of a rolodex contest, but that idea is out of fashion at the moment.
no
I don't think at this point in history limitations drive the the way we do things, abundance does.
I don't see the underlying economic dynamics of the relevance of substitution costs driving the way we do things going away. And substitution costs are all about limitations.
Abundance and limitations are a bit of ying/yang phenomena in terms of driving things, you don't have one without the other.
Igor Stravinsky: "Constraint drives creativity"
(I also don't see Amdahl's Law --which is fundamentally about limitations -- going away any time soon.)
I do agree that there are compounding abundancies present.
Increasingly, the "what do we have the most of?" questions will return "RAM" less and less often.
Nuclear-powered hyperscale data centers in your neighborhood disagree. Not saying it's a good thing, but like it or not, if you ask "what generally drives how we do things", that's probably it.
This is sadly a Betteridge's Law of Headlines situation.
No.
just switch to Rust.
Programmers won't, but LLMs will.
We're in this situation because of laziness. I doubt doubling down on it is the solution.
Programmers will just /goal the LLM to make the code more memory efficient. Then let it run it run overnight.
And it will spend 1 million tokens finding the most memory efficient program:
int main(){}
https://www.youtube.com/watch?v=_n5E7feJHw0