How about not using Java? Then you can have low latency.<p>Average go, rust, c++ and c will outperform amazing java programs, and the former will also be way way more easy to run, troubleshoot, interpret logs from.<p>Java is usch garbage in every stack.
I need a UI which runs well on Windows, MacOS, and Linux, without having to build three different ones. Swing is still easily the best, most consistent, and most native-feeling cross-platform environment. It's much better than QT and GTK in most respects. And Java also runs elegantly on a little platform you may know as Android. I have high hopes for go and rust. But until they have mature UIs, they're out (for me).<p>C and C++ are dangerous languages filled with security failings and footguns, and no modern app should be written in them.<p>It's been my experience that well-written low-level Java code runs at about 75% the speed of good C code. (Of course lazy coders write in cushy Java which is much slower). When written efficiently, Java's biggest slowdown lies in array access (C and C++ array access is fast because it is very, <i>very</i> unsafe). But Java makes up for this in having a GC which will coalesce related objects into the same page and so take advantage of cache coherency effects in ways malloc and free cannot possibly do. I have some allocation-heavy algorithms in Java which are, as a result, significantly faster than well-written equivalents in C.
In heavily performance-engineered code having a GC coalesce memory is a pessimization in all cases.<p>I've done a lot of performance engineering in both C++ and Java. Every optimization available in Java also exists in C++ but the reverse is not true, which is why C++ is always faster. Every example I have ever seen of Java being faster than C++ was just poorly optimized code. The heuristic I use is that heavily optimized C++ is about twice as fast as heavily optimized Java at the limit. And this requires some non-idiomatic and ugly Java that isn't nice to maintain.<p>This doesn't necessarily make Java the wrong choice though. Few organizations prioritize absolute performance above all other things. There are practical tradeoffs.
>Java is usch garbage in every stack.<p>May be true between late 90s to late mid 10s. Both Java and JVM has had enormous of work going into it. 2026 the JVM is pretty damn good pieces of engineering.
I've done some tests with current value classes in latest prototype with full optimisation through annotation. Apparently, everything was being compiled to assembly code with no gc calls. It seems this old school ideology of slow java is about to end in near future. I'm actually intrigued how it will compete with Rust which can't optimise code further while running, while JVM JIT has more info which it could aggressively further optimise, especially hot paths.
Rust? OK.<p>C++ or go? Then you'll have to take a very closer look, because the java JIT is wonderful. A masterpiece of several hands, actually.
If low latency is your goal than you don't want JIT. JIT has two issues in low latency, first the first time through your code isn't compiled yet and so you get high latency. Second, it optimizes for the common case, which means when you hit an exception that exception will be higher latency because everything hits a branch miss.<p>Of course we are talking generals here. Sometimes the above is acceptable and Java/JIT is just fine. Sometimes it is unacceptable and you cannot use Java/JIT. Know your domain.<p>Of course in all cases (C, Rust, C++), you have to understand the system and what it is doing. Every language has a standard library that will do things that are not low latency on you. You have to know which library functions will do what, memory allocation and copies are both things that code often does without thought that are incompatible with low latency. No matter what you need to know what your language does that is against you.
Valid points, but this doesn't mean JIT doesn't work for relatively lower-latency coding.<p>To avoid the compilation etc. hit, common practice is to do some "warmups" before serving users. (Another reply has other ways to avoid this hit.)<p>Handling exceptions is higher latency, but they can/should be optimized out, so you're not hitting exceptions as part of your standard workflow (or even your 1% workflow).
> If low latency is your goal than you don't want JIT. JIT has two issues in low latency...<p>There's startup "AOT cache" via Leyden that speeds up startup. Isn't native speed up it's quite a big boost.<p>Then there's GraalVM that does give you a native image. Real AOT.
It is a matter of skill.
yes, until you need debugging.
> Average go, rust, c++ and c will outperform amazing java programs<p>Not true. Many benchmarks have shown otherwise. it is at least competitive in many areas.<p>> and the former will also be way way more easy to run, troubleshoot, interpret logs from<p>No language will save you from poor logging practices. If you log every debug log it's not Java's problem. No 1 says you have to log the full stack trace if that's your concern. You can configure / strip / do anything. Learn to use the stack.
yeah...no, try low latency when running out of memory, or with more CPU-bound threads than cores...discipline vs almost impossible