Java vs C++ for low latency... Thoughts?
I guess my immediate other is why aren't OSs written in Java?

https://stackoverflow.blog/2021/02/...

The author is more or less correct but they don't qualify their statements very much.

C++ can absolutely be made to go faster (or as fast) than anything else by hypertuning the code to the hardware...but Java is easier to deploy and modify for real applications and you definitely can get Java to go really, really fast if you know what you're doing and also based on the kind of application. Application code like trading systems with relatively predictable memory usage (so you can override the GC so it doesn't cause lag spikes) is a great use case especially with modern JVMs that offer fast and predictable native code generation. tl;dr stuff that aligns with Java's abstractions can be absolutely zoom along with some knowledge of how to tweak the JVM and customize the GC and memory arenas.

And then there's stuff that's going to be faster in C/C++, stuff that really makes use of its ability to precisely direct where each bit of data goes and what exactly your processor is munching on. What C/C++ offer you over Java in reality is *control*, not *speed*. You can turn that control into speed, or low power usage, or whatever you want, that's why they're valuable.

You don't write OSes in Java because it's pointless. C/C++ excel at OSes because they give you control and don't hide low level details, whereas Java abstracts that away and doesn't even let you talk about pointers. If you let Java talk about raw hardware stuff you're destroying the whole reason it's valuable (the abstraction layer it provides).

Judging whether something is faster than something else is very contextual and it really isn't easy to say, because "faster" can mean a lot of different things and each application has a whole fuckton of other requirements that are as important as speed (power usage? high reliability? maintenance? deployment? portability? etc.)

To sum up: Java is fast enough at runtime, but faster at cranking out software, and time to market is a different kind of important latency.

An OS in Java would be a bad fit because the whole point of the OS is to deal with the hardware itself and abstract it. Java is a consumer of that abstraction, not a provider.

Also, one of his arguments why Java is fast enough is that he compares it to external network latency which is always there in trading - but the OS must also react to internal events such as interrupts.

I think there is a lot of What the fuck going on.... In my brain.

I mean... The article can be reduced to: Java better because easier to develop.

For various, in my opinion, subjective facts - but nothing objective.

Even more disappointing is that this article does not even _try_ to be more objective by e.g. doing a comparison of how e.g. a compiled binary (C++) works vs the Java VMs and so on.

It's just a click bait article imho.

@IntrusionCM thought so as well. Most articles doing such comparisons try to sell a particular premise that eventually just flat out crashes on itself.

Kinda weird to write an article about latency and not even mention real time systems.

... to answer your other question regarding OS.

Be it redoxOS (rust) or any other language like Java.

In the most simple form - you will need to have ASM execution to trigger the necessary chooser initialization.

https://gitlab.redox-os.org/redox-o...

You can lookup this example in redoxOS bootloader and google it.

What comes next is up to whatever the author has in mind, of course.

But that's where the trouble starts I guess... As you have to provide now an entry point for the loading of the OS and it's drivers.

Afaik all attempts are dead to have Java as an OS.

Suns Java OS and JNode come to my mind...

http://www.jnode.org/

https://github.com/jnode/jnode/...

Ok dead but source code at least browseable