A bit sad there was no profiling done, or at least the article doesn't mention it. Maybe optimizing Clojure wouldn't have been that hard, could have been only a few places needed tweeking. In any case, Rust is obviously targeting high performance in a way Clojure isn't. Rust is faster than Java, and Clojure can only ever match Java in performance, not exceed it. But still, it's not clear if the author tried to optimize the Clojure version or not?
I agree with you, but I think the assumption here is that we're comparing two code bases that are both trying to be performant. The Rust defaults will probably start off more performant, and the ceiling will be higher as well.
A lot of the performance comes from the different paradigms though, so it's not always an apple to apple comparison. But I also think that's an assumption being made when talking about a Clojure Vs Rust implementation. In the latter, you're most likely implying using mutable collections, fixed size structs, primitive types, and a tighter memory allocation surface. And not surprisingly, those are the same changes you'd make to your Clojure code base to speed it up (most likely).
You're technically correct, but the typical Java program making heavy use of threads has inefficiencies (and incorrectness) that would be avoided with Clojure's higher level async APIs. As it's easier to write idiomatic, performant C than the "faster" ASM.
> Rust is faster than Java, and Clojure can only ever match Java in performance, not exceed it.
The Rust vs Java question translates to the age old C++ vs Java argument, where the counterpoint is that Java can be faster because JVM has no significant disadvantage in code generation but JIT and GC can be faster than AOT and malloc, and then there are many back and forth arguments and nobody changes their mind.
In another sense, ease of use and HLL properties of languages can in practice give performance advantages. Given the same amount of time, the programmer of a more expressive high level language might have more time to iterate and to do algorithm work that end up being much bigger effects than the relatively small differences of compiler code generation.
(The word performance of course also has meanings other than code execution speed...)
> and then there are many back and forth arguments and nobody changes their mind.
except that people routinely rewrite java code in C++ in 2020 and run around the Java code in circles, even when tuning GCs etc etc, à la https://www.scylladb.com/2020/10/06/c-scylla-in-battle-royal... or Minecraft Bedrock edition (C++) vs original Java Minecraft
How many times have there been rewrites from C++ to Java that ended up being faster ?
How many times have there been rewrites from C++ to Java that ended up being faster ?
A couple of times as far as language implementations go (eg JRuby vs CRuby, even before the whole Graal/Truffle thing). However, that's a niche thing, and any JVM implementations have yet to replace the standard runtimes.
As a rule of thumb, I agree that C++ should generally be considered the 'faster' language.
I would be surprised if successful C++ to Java rewrites yielding better speed were rare as we move to multicore and correcness & safety are the bottleneck problems there. But I'm not a Java programmer or follw the scene closely.
Also the narrower niche of C++ means that it often makes sense to rewrite a small part of a Java app in C++, but it rarely makes sense to write a small part of a C++ app in Java. This domain difference can also explain the relative frequency of public "made it faster with C++" posts, since those small self contained uses make good posts that aren't entangled with the bigger application.
Multicore & multithreaded architectures only prove even more problematic as you do context switching and have sync io. That's precisely why it's not just the language (C++); it's also moving to a highly async architecture with shared-nothing, non-blocking architecture to get the best advantage out of your multi-core, multi-cpu machines. (Disclosure: I work at ScyllaDB.)
reply