Hacker News Reader

Comment by redox99 | Hacker News Reader

It would be extraordinary to see a real world rust program use more memory than its JVM equivalent.

I have seen it happen once in an LLM rewrite from java to rust. The modern JVM gc is actually pretty good.

Let's not move the goalposts, the word in question is "performant".

Though even with memory it's not as clear as you assume in the context (which is about browser-based apps). Singular C/Zig/Rust program will surely be more economical than a singular in-browser app due to browser itself having a huge footprint. But what if said user has that browser open all the time anyway as probably most users do? What if there are more than one GUI-rich app, and with browser they share most of the overhead? PLs which allow low-level optimizations offer great opportunities, no arguing. But never say "never" until you know what exact problem yiu have to deal with.

> Let's not move the goalposts, the word in question is "performant".

Even though the word performance was used by a parent comment, I think they used it as an umbrella term. The article and most of the talk around rust discord is primarily about the memory. And JVM is probably the worst runtime you could pick if you care about memory usage.

Assuming this would make this comment less reasonable though. Optimization for memory usage is distinct from optimization for performance in our craft. And it's pretty basic thing.

Rust-based Discord achieves both, though... You can absolutely get an application to run faster while using less memory, given there's enough low-hanging fruit (and with today's software, there certainly is...).

If you're optimizing sorting algorithms, video decoding or compression software, then that's another story, because using more memory can trade time complexity for space complexity in your algorithm (i.e. Merge Sort vs Insertion Sort).

Good, finally! Yet this branch started with the claim which isn't about Discord at all.

This is a thread on the post about Discord and we're discussing the original statement below:

   > All the performance and other arguments are just not true, a well build webapp is often more performant than a native app especially for long scroll lists not even to mention accessibilty, extensions and more.

To which I think Discord's Rust rewrite is actually a great counter example. Epic Games's new launcher could've been too, but it's just vibe slop, unfortunately, not real engineering work.

The announced performance and memory usage also shows that using a browser tab (reducing overhead for separate browser processes) is still not enough to save memory compared to a native application, as this new Discord rewrite, with multiple accounts logged in, uses about the same memory as an empty new Chromium tab.

For starters, logic doesn't work this way at all. Counterexample doesn't make a valid argument against non-absolute statement. And the claim is that in-browser code can be as performant as natively compiled (as you conveniently quoted). So apparently building the case on Discord misses the point twice.

Also for the sake of correctness: Discord CTO said the Rust-based app with 2 accounts uses around 290 MB which is significantly more than even the first empty tab uses (and each of the next will use smaller amount due to sharing).

You cannot separate performance from memory usage. Usually less memory usage for apps comes at the cost of performance and vice versa.

And more memory usage can slow down the whole system, because the system may need to swap and compress memory.

To be direct: this is utter nonsence. Memory usage and performance are different targets of optimization, which often at odds with each other.

I'm not sure you're disagreeing.

more economical

Not sure what this means.

What if there are more than one GUI-rich app, and with browser they share most of the overhead?

Those are called web pages. I don't know what the rest of this comment is trying to say. When a chat room program takes 4GB of memory, there will be optimizations literally everywhere. Everything will work from looking the current javascript to switching languages.

Your "4GB of memory" for "chat room program" is obvious reference to Discord in its Electron-based incarnation. Which certainly proves you sincerely don't understand what that means, and what the rest of my comment is about. It could be my fault, but may I suggest you first read the comment to which mine is answering, just to get the whole picture, so to speak? Missing context may be the root of misunderstanding here because I didn't write it about Discord actually. And even about Electron.

If you're just talking about being on of the 'java can be faster than native programs' people, then show me a java program and I will show you how to make a faster, more consistent, lower memory native program.

Am I? Let me quote myself verbatim:

It's possible for JIT to achieve better performance with that damned bytecode compared to natively compiled equivalent.EOQ

Good JIT is able to dynamically re-optimize code according to present conditions/load which is what can give bytecoded program in certain conditions (which aren't that rare) edge over static native code. Is it possible to make your own dynamic optimization with natively compiled PL which would beat Java, or JS on a relevant case? As a sport, sure, you would just have to make your own bytecode with JIT. Or hand-optimize in every possible way staticly, and just chose the best path when running. You can even gain more by going with assembler. Is it worth extra time, increased attack surface, and higher probability of bugs? Will you even have a good chance to succeed? It is genuinely impossible to answer without full requirements which bind you. Independently, it's fair to say that on RAM side, natively compiled code wins most of the time. Is it something users care about is again a question to think each time anew. To quote me again:

But never say "never" until you know what exact problem you have to deal with. EOQ

Am I? EOQ

Are you asking me what you're saying? EOQ

Is it possible to make your own dynamic optimization with natively compiled PL which would beat Java, or JS on a relevant case? As a sport, sure,

'As a sport' doesn't mean anything, it's just completely possible. I don't even know how you got into java in the first place, that has nothing to do with the current topic. You injected it out of nowhere.

Reply on news.ycombinator.com