6 ms·
> If it evolves. My inexperience with apps that large is spread across dozens of businesses that are 20+ years old. 1M LOC is not a required thing. Just to be
by pron 6mo ago
> If it evolves. My inexperience with apps that large is spread across dozens of businesses that are 20+ years old. 1M LOC is not a required thing.
Just to be clear, the cost of maintaining a program in a low-level language is always higher. That's easily the #1 reason the use of low-level languages has been declining steadily for a few decades now with no hint of a change in direction. What happens in large programs is that low-level languages become slow. So yes, if that program doesn't grow, it will probably not become slow, but they've already paid more on development and continue to pay more on maintenance than any savings they could have made on memory, which are probably zero or nearly that.
The point of my explanation about the RAM/CPU relationship is that a well-balanced ratio is free. If your CPU usage amounts to some X% of RAM "captured" any memory savings below it translates to $0 in savings. It's sort of like ink and paper. They're used in combination so reducing the consumption of one without the other doesn't really save you anything.
> I think it's reasonable to not want a web browser embedded in multiple apps on your computer.
I don't know why that would be reasonable unless you can show me it's a waste of money. Maybe it is, but I'm not sure.
> Slack and Spotify use more RAM than Steam. For what each app does, that seems absurd to me.
But software is written to deliver value to users. Most software has no intrinsic value. Sometimes in an economy you get things that may seem absurd - I can't think of a good example, but say that you can only buy rope in units of 1m - but make sense once you consider the entire system. Could Slack use much less RAM than Steam? Of course! Should it, though? I don't know.
> Again, that's not a bad tradeoff from a development velocity perspective.
And again, what you call "development velocity" is not some vanity metric, but something that can translate to actual money savings for the user more than reducing RAM consumption.
> Do you disagree that making the equivalent app in Avalonia, JavaFX, QT would likely use less RAM and CPU than Electron? Is there not room to trip RAM usage in the Desktop world without harming the CPU?
There probably is, but as I said in the beginning, switching a language is a large investment, not exactly an optimisation (and it might not be worth it).
> But the fact that this type of software has more devs is different from saying the average project has the same considerations.
Well, that depends what you mean by "the average project". If we're counting by number of programs/repos, the median project size may well be a 100 line script. We have to weigh it by something. Number of devs and lines of code are probably highly correlated, so either one would do.
> I estimate 5% of them has any choice over what tech stack they are using in the first place
I don't understand the point you're trying to make. I don't really care what someone working on some small website does because getting that tech stack wrong is of little consequence anyway. For software that "matters", the choice of tech also matters, and you're right that the junior developers (and probably many senior developers) working on those projects don't choose the tech, but somebody does, and these are the choices that matter. For example, you care about Slack's tech choice. That was also some high-level decision. If they got it wrong, it wasn't their junior programmers who made the mistake.
> I imagine if you develop the JVM it's frustrating to continuously talk to people about isolated benchmarks.
Yes, but everyone who deals with software performance has been frustrated by this for a long time. Benchmarks used to be at least somewhat more informative until the late '90s. I don't know how to educate developers more about this, but I hope someone manages to do it.
> Well that is a very different statement from what you said earlier, which is "C++ and Rust are simply not particularly fast for applications, and Java is." You have been painting a picture that it is essentially impossible to top Java with Rust except in the narrowest of situations.
It is generally hard to beat Java in large programs. It is always theoretically possible because you can view every Java program as a C++ program (which is what the HotSpot JVM is) running on some data, but it's hard, and I would say close to impossible for similar costs.
- Capricorn2481 6mo ago> And again, what you call "development velocity" is not some vanity metric, but something that can translate to actual money savings for the user more than reducing RAM consumption I agree with this entirely. > I don't really care what someone working on some small website does because getting that tech stack wrong is of little consequence anyway. For server applications and not tools, probably not. Should Curl have a slower startup time? Probably not. > but they've already paid more on development and continue to pay more on maintenance than any savings they could have made on memory, which are probably zero or nearly that 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. In the server case, you are offloading Dev velocity to your own RAM cost. In the Desktop app case, you are offloading Dev velocity to everyone else's ability to run programs on their own computer. > I don't know why that would be reasonable unless you can show me it's a waste of money. Maybe it is, but I'm not sure /rant Well it's not reasonable as a singular business decision. If we look at everything from the lens of how you can make the most money as a company, Electron is probably the route to go right now. You can reach more users even if you upset more as you grow. For software that is targeting the things I want, I care about the health of the company because it determines how fast improvements get to me. So, in isolation, it doesn't upset me if an app uses Electron. I may not have ever had a chance to use the app if they chose something else. 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 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. I have much more sympathy for the small dev team than a large corporation when it comes to using Electron, specifically because their software is smaller. If I vet and use their product, it likely has less features overall, but does more of what I want. I'm more forgiving of their compromises and I can't be as picky because I chose this product. In the case of apps like Slack, I don't get a choice to use it. I use it for Work, and they develop a lot of stuff we simply don't use. I literally just need it to send text. And so I am a bit less sympathetic to their decision to offload dev velocity costs onto my computer when I don't particularly want to use their app in the first place, and don't believe the majority of those dev hours will be used to help me. 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.