Ask HN: Will programmers write more efficient code during the memory shortage?
91 points by amichail 9 hours ago
91 points by amichail 9 hours ago
Maybe there will even be more interest in the invention and use of more advanced algorithms and data structures that use less memory?
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. 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. > trade time-to-market for hardware cost Enh. I think this only exists for some programmers, who can't write good code fast. Ehm. I would assume your definition of writing good code fast is not what the majority of enterprise developers agrees with. 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. 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. 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. 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. 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. 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). 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 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 “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. 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 > 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. No deadline, no product. Shipping is very important, sometimes more important than what you ship :) 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. 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. 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. 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. 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). 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 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. Switch was notorious for having a few Cloud streamed-games that don't run on the actual hardware. 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) That's memory efficient assets, not memory efficient code. The latter is already optimized for the former. > 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. 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. > 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 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. > 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. 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. 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. 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. My bigger hope (for apple ecosystem) is that macbook neo forces apple to optimize. Devs don't have that scale. 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. 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. 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. It's not like we're stuck back with 640kb... At the very least you probably have 8-16GB of RAM still... 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. 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. 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. 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. 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. 8Gb laptops are about the only tech still selling. Exec's better think long and hard about that. 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. 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. 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. 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. I think they are writing shorter code for to token limits... (Just refactored an app to do this. 60k lines to 20k) > 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. Are you joking? If anything, they'll use even more memory by shoving 8B LLMs in every single app. 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. Only if people start buying computers with less memory, if they just buy fewer computers it doesn’t seem worhwhile. 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. Will you stop using docker to deploy a simple application? No? Didn't think so. AI (like alcohol) is the cause-of and solution-to all our problems. Computer: Rewrite this python code in Go. Make it memory efficient. 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. 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. 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. 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. 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. 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. > 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. currently porting code from Go to Rust primarily motivated by memory efficiency gains 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.. 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. 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!” 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. 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 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. 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. Lets all run a 1GB RAM Terminal application called Claude Code, because even the seven figure payed engineers at Anthropic with Fable and Mythos are too retarded to do any kind of reasonable engineering. 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. Programmers won't, but LLMs will. We're in this situation because of laziness. I doubt doubling down on it is the solution.
patrulek - 6 minutes ago
jpollock - 4 hours ago
exabrial - an hour ago
d5lt5 - 37 minutes ago
Pooge - 2 hours ago
lionkor - an hour ago
laughing_man - 2 hours ago
Pooge - 2 hours ago
armada651 - 2 hours ago
Pooge - 2 hours ago
shakna - 2 hours ago
Someone - 2 hours ago
jpollock - 2 hours ago
Pooge - an hour ago
retired - 2 hours ago
Byamarro - an hour ago
retired - 27 minutes ago
cornstalks - 9 hours ago
kapperchino - 8 hours ago
thewhitetulip - 5 hours ago
inigyou - 5 hours ago
thewebguyd - 5 hours ago
elcritch - 4 hours ago
aabdi - 4 hours ago
FridgeSeal - 3 hours ago
thewhitetulip - an hour ago
dabinat - an hour ago
throwaway2037 - an hour ago
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. > Optimizing memory server-side directly translates to cost savings for companies.
Byamarro - an hour ago
devmor - 5 hours ago
thewebguyd - 5 hours ago
msalsas - 35 minutes ago
ChrisMarshallNY - 4 hours ago
jopsen - 2 hours ago
timacles - 4 hours ago
devmor - 3 hours ago
throwaway2037 - an hour ago
devmor - 4 hours ago
hashmap - 4 hours ago
jimnotgym - 2 hours ago
andix - 9 hours ago
KronisLV - 8 hours ago
Stevvo - an hour ago
thewebguyd - 5 hours ago
VohuMana - 31 minutes ago
timacles - 4 hours ago
operatingthetan - 9 hours ago
laughing_man - 2 hours ago
Dwedit - 4 hours ago
tayo42 - 9 hours ago
applfanboysbgon - 5 hours ago
andix - 9 hours ago
thomastjeffery - 9 hours ago
rvz - 9 hours ago
andix - 9 hours ago
cco - 3 hours ago
throwa356262 - 2 hours ago
dehrmann - 2 hours ago
naet - 8 hours ago
lesuorac - 5 hours ago
nrmitchi - 9 hours ago
justincormack - 40 minutes ago
sim04ful - 33 minutes ago
tinco - an hour ago
dainiusse - an hour ago
mherkender - 9 hours ago
xp84 - 9 hours ago
cryo32 - 2 hours ago
Panzerschrek - 2 hours ago
citrin_ru - 2 hours ago
harel - 2 hours ago
kantord - 9 hours ago
devin - 9 hours ago
herbst - 2 hours ago
jbird99 - 3 hours ago
martinald - 9 hours ago
pnikosis - 9 hours ago
smackeyacky - 8 hours ago
jswelker - 5 hours ago
smackeyacky - 5 hours ago
Shitty-kitty - 5 hours ago
winstonwinston - 9 hours ago
sneilan1 - 9 hours ago
winrid - 8 hours ago
xp84 - 9 hours ago
bborud - 9 hours ago
HaloZero - 9 hours ago
WheelsAtLarge - 8 hours ago
antinomicus - 8 hours ago
laughing_man - 2 hours ago
__mharrison__ - 2 hours ago
asp_hornet - 9 hours ago
t-writescode - 9 hours ago
furyofantares - 5 hours ago
Werewolf255 - 4 hours ago
int3trap - 9 hours ago
kantord - 9 hours ago
devin - 9 hours ago
johanvts - 9 hours ago
casey2 - an hour ago
comrade1234 - 9 hours ago
xnx - 6 hours ago
segmondy - 8 hours ago
cheesecakegood - 9 hours ago
koliber - 9 hours ago
novafunc - 9 hours ago
sudoshred - 9 hours ago
jklein11 - 9 hours ago
garyfirestorm - 4 hours ago
physix - 9 hours ago
ojbyrne - 8 hours ago
Insanity - 9 hours ago
MaulingMonkey - 4 hours ago
__s - 7 hours ago
jinpan - 9 hours ago
hollowturtle - 9 hours ago
winrid - 8 hours ago
holoduke - 3 hours ago
DANmode - 3 hours ago
Joker_vD - 9 hours ago
thewhitetulip - 5 hours ago
Uptrenda - 9 hours ago
devin - 9 hours ago
dosisking - 3 hours ago
wseqyrku - 9 hours ago
gregw2 - 9 hours ago
ms_menardi - 9 hours ago
wseqyrku - 7 hours ago
antisol - 2 hours ago
Hahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha > Will programmers write more efficient code during the memory shortage?
Lionga - 2 hours ago
reinitctxoffset - 4 hours ago
tristanj - 9 hours ago
BearOso - 9 hours ago