Hacker News Reader

Comment by tmp231 | Hacker News Reader

I remember about 10 years ago the promise was that JRuby was going to let ruby be basically as fast as Java for many things. Invokedynamic and all that.

View on HN

It can be with work. This is basically true of all languages. I remember telling my team that I wanted them to use Java instead of python for some new service we were building because I wanted it to scale better. They were not happy about it, and they coded up two versions, one in python and one in Java. I was shocked by the results, they performed roughly equally in terms of latency and scaling. When I dug into it, the very abstract Java library that gave them the power of python ran about as fast as python. They could get rid of that library which made them far more productive, but then the project took longer and cost more.

In fairness, the Java version had an easier path for optimization, but there are no free lunches.

> When I dug into it, the very abstract Java library that gave them the power of python ran about as fast as python. They could get rid of that library which made them far more productive, but then the project took longer and cost more.

Sounds like they were determined to write Python on Java. Doing it that way likely has a lot of performance costs. However, you can’t assume that idiomatic Java code would take that much longer than Python code for a team that was familiar with Java. Likely it comes down to which languages and frameworks a team is familiar with.

I am curious what library was this and what was it doing.

We used spring expression language for dynamic evaluation of (user-defined) expressions in our code and for most cases we could compile and cache the expressions after first usage and invoking them was really fast and close to pure java expressions.

We also had some JVM-python interop which we eventually got rid of (in favor of kotlin) because we were unable to optimize it after a month of effort and it continued to be the biggest bottleneck in the system.

So I am not entirely convinced that there could be real-world usage scenarios that inherently demands so much runtime dynamism that most benefits of JVM optimizations are nullified.

Of course, I'd love to be enlightened otherwise, but rather happy with JVM as of now.

There is nothing at the JVM level that would disallow such dynamism. Clojure, JRuby, JPython all can run on the JVM.

Also, if you are looking for interop, then GraalVM might be worth a look — not the better-known AOT part, but the runtime one, which can seamlessly do interop between a number of languages, and it even optimizes between them!

Yes, being possible and being performant are two very different things.

What I intended to convey in my previous comment was that using strategies like pre-compilation (eg. Spring EL) it is possible to get good performance even for dynamic logic not known at runtime.

So I was curious what was so dynamic about this use case that JVM performance drops down to pythonesque level.

I don't want to speculate - maybe there is something that JVM is unable to optimize; maybe it is something weird happening in the library; or maybe python has gotten really better in recent past or this use case was able to benefit from some python lib with native bindings.

Seeing all the dynamic languages running on top of the JVM without any trouble, I doubt the answer should be sought at that level.

It was the Google datastore library maybe 5-7 years ago.

> I remember about 10 years ago the promise was that JRuby was going to let ruby be basically as fast as Java

I’m pretty sure it was more than 10 years ago that Charles Nutter wrote a detailed description of why that wasn’t going to happen without breaking compatibility with Ruby, identifying the specific language features preventing that.

The Truffle based implementations of dynamic languages get close depending on what you’re benchmarking.

https://stefan-marr.de/papers/dls-marr-et-al-cross-language-...

Reply on news.ycombinator.com