[vinay_ys]

> But then again, most high frequency trading also runs on the JVM, so it can often be worked around.

JVM is an awesome piece of technology. And you can do robotic control systems to high-frequency trading systems with it with careful programming.

But I've seen a lot of Java code running in production suffering from latency jitters and needing continuous profiling and optimization by a small group of performance engineers while the majority of application engineers keep adding to GC load.

> For this specific use-case, I don't think there is really an alternative, except for specifically a hand-crafted system

Yes, but I think the handcrafted system doesn't need to be very complex. It can be quite simple and easy to understand and tame to your needs as your scale and complexity grows.

[randomopining]

Doesn't it have the new GC's that are supposed to be minimal pause and gamechangers?

[valenterry]

Yes, but for GC still must happen and sometimes even milliseconds can be a problem, depending on the use-case. It really depends on what your business does, so the OPs concerns with the JVM are very valid.

At the same time, I think (while not being an expert) that in the majority of the cases, the GC will not be a problem and that the time you can save from using Akka Cluster allows you to optimize your system more than enough to make up for any GC latency problems, in almost every system.

The only technology that might be better/comparable here is the erlang VM, but I have never used it myself.