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.

▲

CyberDildonics 16 hours ago | parent [-]

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.

	▲	broken-kebab 2 hours ago \| parent [-]
		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