> building and deploying Function/Serverless and Microservices most

For those you may be better with IBM OpenJ9:

https://www.eclipse.org/openj9/

It also integrates with CRIU so you can almost instantly start/stop the JVM:

https://blog.openj9.org/2022/09/26/getting-started-with-open...

I keep forgetting about J9 but they're not doing themselves any branding favors since there actually is J17 on J9 :-/ https://github.com/eclipse-openj9/openj9/blob/openj9-0.35.0/... (Also that 0.35 versioning ...)

As best I can tell, these are the docker images: https://hub.docker.com/_/ibm-semeru-runtimes

    $ docker run --rm ibm-semeru-runtimes:open-11-jdk java -version
    openjdk version "11.0.17" 2022-10-18
    IBM Semeru Runtime Open Edition 11.0.17.0 (build 11.0.17+8)
    Eclipse OpenJ9 VM 11.0.17.0 (build openj9-0.35.0, JRE 11 Linux amd64-64-Bit Compressed References 20221031_559 (JIT enabled, AOT enabled)
    OpenJ9   - e04a7f6c1
    OMR      - 85a21674f
    JCL      - a94c231303 based on jdk-11.0.17+8)

The phoronix benchmarks seem to imply that J9 performs worse overall.

https://www.phoronix.com/review/java-openjdk-mid22

There are a lot of other neat parts for graal that will likely be beneficial. One of the big benefits of graal is that it makes implementing guest languages a snap (via the truffle framework).

So you can get all the operational benefits of the JVM + a nice set of languages to play with along with interopt cross language (python calling java calling ruby calling perl, etc).

Here's the languages they already have.

https://github.com/oracle/graal/blob/master/truffle/docs/Lan...

That particular claim/goal used to get me excited (run any language on GraalVM), but the reality seems to have worked out to be a very large asterisk next to that claim.

From what I can tell, the effort to get any particular language running on Graal is non-trivial, leading to that relatively small list of supported languages - most of which seem to be custom dialects in one fashion or another. Perhaps I'm wrong though...

Is it a small list? Especially if you count ILs like LLVM bitcode or WASM, it probably includes most of them.

Many of the languages people use in the real world are really large, really old, really hairy and rely heavily on native extensions that poke arbitrary interpreter internals. Truffle at least makes these implementable with higher performance, and the team size needed to get that done isn't infeasible. But implementing a Ruby or Python will never be a five minute job regardless of what tech you use.

It's small in that nearly half of the published list is academic languages and dialects, and the other half seems to be custom dialects of languages.

While LLVM or WASM support is nice, most modern languages are not compiling to either one by default, and likely means it's not "turn key" to get your system running on Graal anyway.

WASM support makes it possible to run code where there are native compilers for the language.

GraalVM team member here. Implementing any mainstream language is indeed a challenge, more so if you have to maintain bug-compatibility and cope with all the bits of bad design that went through the cracks in the de-facto implementation. Truffle is not for beginners, but knowing the basic set of features e.g. partial evaluation, deoptimization... can get you very far already e.g. you can easily speedup any interpreter by 10X or more with minimal changes.

How long does take to implement a programming language? Well, from hours to years... depending on the language. To make my point; how long would it take to implement a JVM? A JVM is a complex beast, so I would myself guess from years to a decade probably, what if I told you, that Espresso was written in just 6 months by an intern and a seasoned engineer... in just 6 months it was able to Minecraft and even run itself. I assure you there's no magic here, and certainly no blinding talent either; the only reason for this unheard productivity was Graal/Truffle. So, whenever I talk about Espresso I always give all credit to Graal/Truffle, it is a sublime platform for implementing fast languages and runtimes, of which Espresso is just a byproduct.

Thank you for the work on GraalVM!

Just a tiny side note, a basic toy JVM is actually not that hard (without JIT, trivial GC, limited standard lib) from personal experience, of course a performant/having feature parity one is indeed impressive (though I yet to play with Espresso!)

It can run Javascript with similar peak performance than V8 with a tiny tiny fraction of development than what went into the latter. (Of course it is possible only due to it leveraging the many many dev-hours spent on the JVM), it is the fastest Ruby implementation by an integer factor and it can run C dependencies (often used by Python/Ruby) as well, and even optimize across language boundaries.

The smallish list of languages is just due to lack of effort, plus lack of immediate benefits — it is not hard to create an alternative language implementation. It is very hard to create one that is 100% drop-in replaceable with the real thing as every sufficiently complex program will depend on implementation quirks as well.

Regarding Javascript: there are at least two or three mature Java implementations out there, and many more non-Java ones. Its inconsistencies and most implementation gotchas are well-known by now. Also, it's a comparatively simple language that has not experienced as much organic growth as Python, Perl, or Ruby.

I am still impressed that it can beat V8 handily without extensive further optimization work in the JVM, but it's not that surprising.

There are no plans to move Truffle to OpenJDK.

On the other hand, Truffle is just a Java library (with some special handling when used by Graal JIT compiler), so one will be able to just simply place it on the classpath.