The RAM shortage could last years

Thank you for walking me through the CPU cycle hogging RAM thing, that makes more sense. Obviously I have a lot to learn here. For the record, I don't have a problem with Java. And in rereading the whole conversation, I can see you stipulated for exactly what I'm arguing about early on

> The question isn't why apps use a lot of RAM, but what the effects of reducing it are. Redcuing memory consumption by a little can be cheap, but if you want to do it by a lot, development and maintenance costs rise and/or CPU costs rise, and both are more expensive than RAM, even at inflated prices

That sums up what I've been getting at much better.

> and will cost much more to evolve, costs will never drop and may well rise. These costs are higher than the RAM they saved, which was free anyway, because it couldn't be used for anything else

I guess I'm suggesting If it evolves. My experience with smalller apps is spread across dozens of businesses that are 20+ years old. 1M LOC is not a required thing. In fact, for many businesses, you probably couldn't reach that many LOC without inventing busy work for devs. Sometimes my job is ripping features OUT that a different dev company put in, and nobody knows why anymore.

> The people begging are sometimes right and sometimes really wrong. They are sensitive to certain things but don't consider the full picture

That's a true statement in isolation. I think it's reasonable to not want a web browser embedded in multiple apps on your computer. Slack and Spotify use more RAM than Steam. For what each app does, that seems absurd to me. Again, that's not a bad tradeoff from a development velocity perspective.

> First of all, this is the class of software that most people rely on the most by far. It certainly contributes more economic value than other software.

But the fact that this type of software has more devs is different from saying the average project has the same considerations. I wouldn't tell someone to use Kubernetes because FAANG uses it, and that means a lot of devs use it. If you estimate 50% of developers to be working on this kind of software, I estimate 5% of them has any choice over what tech stack they are using in the first place. So when you are making tech stack recommendations and saying "C++ is not fast for apps", you are talking to the other 50%.

> There is nothing you can learn from it because you don't really know what it is that's been measured

That's true. I downloaded the benchmarks and ran them myself and played around with them. But I lean on others for technical evaluation. My understanding of low level programming ends at toy projects and what I've read about cache/cpu. I imagine if you develop the JVM it's frustrating to continuously talk to people about isolated benchmarks.

Edited out a lot of rhetorical arguing after rereading the conversation

All benchmarks tell the truth about themselves. That has never been what makes benchmarks good or bad. The worst and best benchmarks ever made are both truthful about their results.

But a good benchmark suite is one that covers a variety of different problems and/or programs similar to a significant portion of production software. The Benchmark Game is neither, plus it's confusing because it often compare things that measure the sophistication of the algorithm while making it seem it measures something about a language (you don't need to be deceitful to confuse). So no, I don't think it's a good benchmark suite at all.

> The Benchmark Game is neither.

And makes no claim to be.

Here's something that could reasonably make those claims:

https://dl.acm.org/doi/10.1145/3669940.3707217

Oh! It's only Java.

> Should Curl have a slower startup time? Probably not.

Of course, but I don't think anyone would consider curl to be of little consequence. There are many small programs that are very important, but in general more value is in larger programs, and I don't think it's hard to see that. A large program costs tens of millions of dollars per year. Companies don't pay that unless the software more than pays for itself. When it comes to small programs, because they're small, competition is also easier. Five different people may identify the same small problem to solve with five different programs. One may end up being consequential, and the rest won't be.

> One key detail of desktop apps is every performance compromise is multiplied across all your users. It doesn't make much business sense to spend hundreds of dev hours to spare your server 4gb of RAM. But it has a much bigger impact across a growing number of users.

Yes, and I don't want to appear as if I claim that, say, Electron isn't a problem. It's just that I'm not sure it's a problem, and I'm trying to say that things are more complicated. If there is a problem, of course it affects many people, but I'm not sure there actually is one. My point about RAM isn't that it's no big deal if you waste it, but that using a lot of it might not be waste at all (in other words, that the RAM you're using is effectively free, as it cannot be used for anything else). So if an Electron program uses 6GB of RAM, and 4 of them are a waste - even if 2 of them are a waste - that's a problem. But even if you can write such a program that only uses 1GB, that doesn't mean that the other 5 are a waste at all. Using less RAM isn't necessarily more efficient if the RAM you saved can't be put to good use.

I'm also making a separate claim that even if some of that RAM is a waste, it could be offset by a lower cost of development, but these are two different claim.

In short, what I'm saying is that it's complicated.

> The problem is when everyone does that. If the expectation becomes "everyone has a lot of RAM so just use Electron", then where does that end? Now we need more RAM, even as it gets more expensive, to run apps that are not particularly novel.

It's not so simple! First, we need more RAM because we have more compute. To some degree it's like ink and paper. You can't enjoy more ink unless you also have more paper. Second, because some RAM can be converted to CPU (through moving collectors or arenas) the overall cost of running some computation can be lower if you buy more RAM. Third, once you already have that RAM, how much of a problem is it if some silly program uses a lot of it? The Electron apps I've seen have little problem being paged out to SSD, and they page in fast (paging in even 5GB takes about 2s, and you usually don't need to page in so much at once).

> It's not surprising people are growing frustrated. Dev Velocity is not a vanity metric, but it's not inherently moralistic either. Sure, a company could "scale" faster replacing all of their support staff with an AI chatbot, but that doesn't mean I have to like it.

Who is growing frustrated? Hackers on HN? If there's actual demand, and if the economics really support the claim that it could and should be done, then alternative products will have a competitive advantage. I'm always dubious when people make claims that seem to me to run counter to how the market behaves. That doesn't necessarily mean they're wrong, but it is a significant point against the claim. If a lot of people think they're paying to much for what they're getting and it's possible to pay less, such a product offering would be a huge success.

> I use it for Work, and they develop a lot of stuff we simply don't use.

Serious question: What would you be using the RAM Slack consumes for while at work?

If you could use that RAM for something more productive or if it meant your work machine could be significantly cheaper, then that's a very good argument. But if it's just about not liking to see a large number of something your boss has already paid for when a smaller number could do, even though they don't really make smaller hardware, then that could explain why there isn't a real pressure to do things differently.

> I literally just need it to send text.

Let's say the job could be done in 500KB and that Slack uses 5GB. But you already paid for 8 or 16 GB of RAM. Unless you could use that 5GB for something better while you're sending the text, why do you care that the number goes up? It doesn't cost you anything.

> In the case of VSCode, from what I understand, they have to spend a lot of dev time anyway to make Electron work for them. I don't think the value add is as cut and dry when your product needs to run fast.

I have no idea why VSCode chose Electron and whether it's a good or bad decision (I don't know how much it played a role, but I think that the ability to write plugins in JS/TS helps them, as there are so many JS/TS developers), but it doesn't bother me because the performance is good enough and it doesn't seem to hinder my use of my machine for anything else I run. If at some point it starts bothering me, I'll look for leaner alternatives.

I don't understand what you're trying to say. I said that the Benchmark Game is not a good benchmark suite in the sense that it does not measure language speed differences since 1. it compares different algorithms, and 2. it doesn't cover some of the most important use-cases that languages/runtimes optimise for [1]. That's all. I'm not saying it's deceitful, I'm saying it's just not good comparison of language speeds. Are you agreeing or disagreeing?

[1]: In particular, Java was designed to overcome some of the biggest performance issues of low-level languages that has plagued a large number of applications: memory management when objects are of varying sizes and lifetimes, concurrency (especially lock-free data structures), and dynamic dispatch, which grows in use as applications grow in size and complexity. Not a single one of these is covered in the Benchmark Game, which focuses on small, very regular, batch workloads, the very things that low-level languages have always been good at, and none of the areas where the performance of low-level languages has traditionally (and to this day) suffered and which led to different compiler and memory management designs.