3 ms·
I think people should just use what they're comfortable with and what is the best fit for the problem. My perspective to web development isn't public websites,
by vardump 11y ago
I think people should just use what they're comfortable with and what is the best fit for the problem.
My perspective to web development isn't public websites, but web servers running on embedded devices and/or workstations.
My issue is that JVM forces me to marry it. I can never make a C-ABI library with it. However I need to run same code also in places where JVM is not available or an option, that limits JVM's usefulness to me.
Other issues I have is it's much harder (and often impossible) to extract maximum performance out of JVM. It's true JVM is as fast as naive C/C++ code and much safer too. There are things you can do to slightly improve performance, but it often means the code is far from idiomatic Java (or whatever language it is that compiles to bytecode).
I like how JVM land can dynamically optimize on the fly according to runtime information. How it can inline at runtime across different .jar "libraries".
But in C-ABI land I can ensure memory locality of reference, directly map objects to memory mapped file, and use SIMD and other processor features for maximal effect. I can deal with multi-socket NUMA issues and allocate CPU local memory. There are cases where SIMD gives 10-40x boost (like sorting code) and a ton of cases where you get 2-10x gain.
I can even compile C/C++ code into pretty fast Javascript that runs in a web browser! Sure there's GWT, but it doesn't come near when it comes to end result performance. In fact, with some care, the same C/C++ code can run on practically any platform. Windows, OS X, Linux, Android, that 8-bit microcontroller, web, DSP, GPU -- you name it.
I do hate the days when some piece of code poops all over stack and heap and all you have is a corrupted core dump to work with.
Of course I can use JNI, but then I have two problems.
JVM banana is tasty, but the gorilla and jungle comes with it.
Rust apple looks promising and so far it seems like I get only the apple I need. On top of that it looks like in addition to memory safety, I'm also getting compile time concurrency guarantees. That's something JVM/Java never gave me.
If one day Rust could provide me dynamic runtime optimization features, that might be all I'll need.