Not at all. The constraints for ultra low latency are the same whether you use C++ or Java: No blocking IO, no dynamic memory allocation. Using the right libraries such as this one, Java can do a surprisingly decent job while keeping the code more accessible to a layman developer than if it was C++. You still need C++ for applications where maximum mechanical sympathy is required (cache alignment guarantees, etc.) but if you have low latency / medium volume Java often does the trick.

Well said and I couldn't agree more. There are top market makers and banks using Java for a fact. And other C++ firms as well. Some of them are considering or have considered the move to Java. Some have already done this move. Some will never do. I'm certain that it is trivial for a C++ programmer to code in Java. The opposite of course is not true. The whole point of Java as a language is to be higher-level than C++. I don't know if people have realized, but with GraalVM it is now possible to compile Java code entirely to native code ahead-of-time, like it is done with C++. Even before GraalVM there was already the -Xcomp option to force JIT compilation in the very first pass. However that does not necessarily mean that AOT is always preferable over JIT. It is not. Runtime profiling information so you can determine the critical path (hot spots) is amazing for some optimizations, such as aggressive inlining.

> I'm certain that it is trivial for a C++ programmer to code in Java.

as someone that knows both, I've made this assumption before too

it has turned out to be not true on almost all occasions

That's fair! I would assume that was due to your comfort zone and muscle memory. Not because you found Java to be harder than C++. Usually a higher level language is easier to grasp, handle and manage than a lower level one.

I think their complexity is very different

C++ the language is exceptionally complicated, but the ecosystem is relatively simple

Java is the opposite, the language itself is simple enough but the ecosystem is humongous (spring/J2EE, maven/gradle, n^2 logging frameworks/adapters, application servers, anything involving classloaders/annotation processing/dynamic bytecode manipulation, ...)

syntactically they look similar, but other than that there's not much in the way of transferable skills between the two

Totally agree! Because of the zero-garbage and no-gc requirement we don't even use the JDK. We use Java as syntax language and write everything from scratch, even the data structures (java.util.HashMap produces garbage). So the bloated Java ecosystem does not affect us too much.

yeah we're the same, our java looks very much like C

unfortunately all the data from outside our strange world still needs to be brought in and cleaned up :)

I do it better, I free myself from as much as I can of toxic SDK (c++ and java SDKs are filthy toxic).

Assembly, worst case scenario plain and simple C99+.

dynamic allocation is fine as long as it is under control, as it's just a pointer bump

what you never want is to trigger the GC at a bad time

(you can do cache alignment too relatively easily)

Doesn't dynamic allocation expose you to memory fragmentation or other non-deterministic phenomenons?

With semantic and fine-grained control of your allocations, and with a memory paging system on top of that, getting fragmentation is tough...

LOL you have a point. But this is subjective. Someone could argue that a highly complex C++ system is masochism. The reality is: a lot of successful market makers, prop trading firms, banks, etc. use Java for ultra-low-latency financial systems. And of course some successful companies use C++ as well.

Numbers aren't subjective. High-performance is a measurable claim and shouldn't be entangled with language-complexity matters.

Totally agree! My understanding because of the use of the word "masochist" was that it was possible but difficult. Not that one language was better/worse than the other, in terms of performance.