Ask HN: Why hasn't JVM become the defacto implementation for dynamic languages?

[bryanalves]

The JVM has been around for a while now. It's stable, mature, and fast. Lots of languages have started to get ported over to the JVM, and things like Scala exist to make the JVM a great computing platform.

With recent dynamic language implementations on the JVM meeting or surpassing performance of the "native" VMs, why hasn't there been a move to have the JVM become the default implementation?

Jython is a great example. It's fast -- faster than CPython in a lot of cases, and it doesn't have the GIL. And it gets access to the full Java environment if it wants it, presumably including things like Clojure, JRuby, Scala, etc. where appropriate.

This seems like a win/win to me, yet there is almost no traction in this direction. I can think of a couple of reasons why this might be:

1. I'm wrong and Jython isn't actually any faster.

Even if it isn't faster, the better environment should make up for this.

2. Integration with Java land isn't that much of a benefit.

Having access to all of this stuff -- but not being forced to use it -- seems great to me. There's no real downside and lots of potential upside, including increased market penetration in enterprise environments.

3. The JVM won't benefit from dozens to hundreds of programmers from python/ruby/etc applying what they've learned in their respective languages to it.

Maybe this is a case of too many cooks in the kitchen. Linux seems to do well with the "shittons of developers working simultaneously" method of doing things, why can't the JVM?

Even if the language developers don't work on the JVM at all, so what? See points 1 and 2.

4. Lagging behind by a few versions (Jython is at what, 2.5.x?) is a bigger deal than I'm imagining.

This could be made up for within a year or 2 if languages committed to the JVM as their default implementation.

5. Non-perfect compatibility breaking lots of stuff

This is a major concern, right? It's not like Python3 isn't doing the same thing right now, or seemingly every version of Ruby doing the same thing. Oh wait, they do.

Maybe the JVM isn't the right vm to standardize on; maybe LLVM would be more appropriate. I don't know. What I do know is that it seems silly for a bunch of language designers to all be having a big case of NIH and writing their own vms and bytecode interpreters.

Thoughts?

[SoftwareMaven]

One of the really big issues with the JVM (outside of the "It's Java" or "Scary Oracle" stuff) is startup time. Many dynamic languages came into being to scratch an itch for scripting. In those cases, being able to start up quickly is important.

Clojure, Groovy, Scala, and others have shown ground-up dynamic languages on the JVM can be very good and very successful. But that doesn't mean there isn't value outside of the JVM, too.

Once you say "All languages must be on the JVM", you significantly limit innovation, since you are tied to what Oracle decides is worthwhile. For example, it probably makes sense for there to be no tail-call optimization in the JVM, but that is pretty important for a very large class of languages.

[runT1ME]

Scala is pretty much the opposite of a dynamic language...

[jfasi]

I think the reason is both technical and social.

The JVM has a very hard time integrating existing C code and extensions. For instance, in the case of python, Jython lacks the ability to take advantage of the significant number of modules written in C.

Consider what this means for performance. Imagine a pure python module that attempts to import a C submodule for performance, and falls back on on the pure python implementation specifically to allow it to run on non-CPython implementations. json is an example of such a module.

This module was likely engineered and architected with C module optimization in mind. I'd assert that in most cases the pure python module is a crutch to allow a CPython-targeting module to run on other implementations.

This leads into the social reason. Community takes a long time to build and using the JVM for dynamic languages is a relatively new trend. The JVM is a very mature, well-optimied technology for static languages. It is only now that dynamic languages are starting to gain traction on it.

[icebraining]

There's a recent blog post[1] by one of the CPython core devs. He talks about Pypy, not Jython, but I think it applies too:

Personally, I think the status quo in this space is in a pretty good place, with python-dev and CPython handling the evolution of the language specification itself, as well as providing an implementation that will work reasonably well on almost any platform with a C compiler (and preferably some level of POSIX compliance), while the PyPy crew focus on providing a fast, customisable implementation for the major platforms without getting distracted by arguments about possible new language features.

[1]: http://www.boredomandlaziness.org/2011/08/of-python-and-road...

[vorg]

When Oracle bought Sun, Java lost its mojo. Sure, Java still has many more installs, but who would trust Oracle with it medium- to long-term. Microsoft was clearly evil when Java was born, and in the late 1990's. But Microsoft turned, created C#, and has slowly nurtured it so it's now better than Java in many ways, e.g without Java's rotten type erasure, snappier in Visual Studio than JVM-anything in Eclipse, with the dynamic keyword, ... Now everyone knows Oracle is more evil than Microsoft, and the JVM is just one of many platforms, alongside .NET, javascript ..., we can develop to.

[teyc]

Dynamic languages were not very well served until invokedynamic came about.

If you have a careful look at the Java bytecode, every non virtual function call is resolved at compile time. However, for dynamic languages, function resolution is at run time. And at the moment, it can only be done via reflection, and not amenable to JIT optimizations. However, this is all changing, and if Java could shed some of their static classes (which affect start up time), it has a good chance going forward.

[jp]

Sun was a supercomputer company. Java is the alternative to IBM operating system VM's running on mainframes. Nobody has that kind of hardware just lying around. Java was designed to run on $1000 SCSI hard-drives and 32Gb of RAM. The focus is on standardization, scalability, portability, buzzwords and expensive catering.

The guy that made the Chrome Javascript VM sat with a laptop in a small house in the Danish countryside. Because the focus was on normal everyday hardware. And guess who that was ? A former Sun Java VM programmer. So the "just use Chrome" developer demographic is sort of unintentionally ironic when they, well, open their mouths. Why do they think Chrome is so memory hungry anyway :P Well, the problem is actually the same problem that you have in other UI frameworks where event listeners and DOM references never gets released from the UI side. And there are some strange issues with anonymous functions and closures, but I do not know enough about that to comment.

Java is fine, but Javascript does not need to be Java. Apple just screwed up the LiveConnect bridge in Safari just to piss us off.. transition us all to a better state of mind. Or maybe that was Oracle, I have no clue anymore. The guy that worked on Jython probably felt very alone doing all the work and JRuby is only here because of desperation from Sun. And Scala is the solution for people who never finish anything. So maybe I should.. oh shiny..

http://www.businessweek.com/globalbiz/content/nov2008/gb2008... http://labs.teppefall.com/2011/08/why_not_use_java_and_invok...

[daniel_solano]

> Java was designed to run on $1000 SCSI hard-drives and 32Gb of RAM.

This is plain wrong. Java was originally developed as a language for embedded devices, not servers. Later, it was targeted for the web (remember applets?).

These days Java may be best known for being "enterprise", but that is hardly its origin.

[mtogo]

The JVM is mostly nonfree, controlled by Oracle, and isn't easily or readily available on systems other than Windows. I cringe whenever i see an application of some sort that relies on the JVM, as i know there's a rather small chance of that application working properly.

In theory it's great, but in practice it sucks.

[amorphid]

The JVM is available on Linux and Mac OS X, too.

[Joakal]

If JVM is purported to be so good in terms of performance, why not just create a JOS too? The VMs is only as fast as the OS from my basic understanding. It would mean an easy port of applications in JOS to other JVMs too.