undefined | Better HN

0 pointsbrabel2y ago0 comments

> Based on hearsay, the JVM often competes in language performance closer to C++, and has probably the best garbage collectors in the world as well as the best developer and operational tooling. How much do other platform developers leave on the table by ignoring the JVM these days?

I am mostly a Java developer, but have had the opportunity to play with Common Lisp and many other languages.

While it's true the JVM is very performant, its performance actually comes at a cost: it has a JIT, Garbage Collector, a whole lot of machinery for Threads/VirtualThreads, JMX etc. all of which comes at a cost... thanks to multicore processors and lots and lots of RAM being available, this translates in really fast performance for Java applications... so that cost may be advantageous to you.

Common Lisp applications are much lighter than Java applications from what I've actually measured given its simpler model... it basically compiles Lisp code to machine code directly and then runs that (Java runs bytecode, and then at runtime the JIT selects which code to optimise, which continues to happen for the lifetime of the application). I would bet money on any application written in Common Lisp being significantly lighter, and hence "greener", than the equivalent Java application, while still running at nearly the same speed, or even faster.

For short running programs, Common Lisp is incredibly fast at starting up and getting stuff done - it competes with C and Rust in that regard, not with Java.

> How much do other platform developers leave on the table by ignoring the JVM these days?

Common Lisp tooling is integrated into the language itself. You can inspect the machine code it generates, ask it to instrument every function so you can profile, and so on without even needing any external tools - it's all built-in... but of course, using it from SLIME or SLY (in emacs) makes it a lot more pleasant. If you think Java tools are better, I believe you may not know Common Lisp very well.

0 comments

4 comments · 2 top-level

andsoitis2y ago· 2 in thread

> While it's true the JVM is very performant, its performance actually comes at a cost: it has a JIT, Garbage Collector, a whole lot of machinery for Threads/VirtualThreads, JMX etc. all of which comes at a cost... thanks to multicore processors and lots and lots of RAM being available, this translates in really fast performance for Java applications... so that cost may be advantageous to you.

Here you say “it comes at a cost” twice, but you don’t say what the cost is! Or am I missing something?

brabelOP2y ago

The cost is on the things mentioned themselves: JIT is not free at all, it may take more CPU power than your actual application during some period!

You can actually tell the JVM to not JIT... try that and see just how slow your code runs... it may give you an idea of how much it costs in terms of energy as well if you're able to measure that (I don't know how much that cost would look like, to be honest, I can only imagine it's a significant proportion of the total).

pjmlp2y ago

Or maybe AOT compile, there are two free beer options now, or make use of JIT caches, there are also a couple of implementationst that do it.

That is the beauty of languages with multiple implementations.

pjmlp2y ago

That "cost" ignores the ecosystem of Java implementations, including AOT ones, embedded deployments, and real time implementations.

Also lets not forget the influence of Lisp/Scheme people like Guy Steele on how Java turned out.

"We were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."

Full Lisp would have been better, but apparently Lisps in desguise like Dylan and Julia, are the best mainstream is willing to take on.

j / k navigate · click thread line to collapse