truffleruby VS graaljs

I think it would be worth mentioning GraalVM and https://github.com/oracle/truffleruby in competitors section.

GitHub page has some info: https://github.com/oracle/truffleruby#current-status

My question is, how viable is TruffleRuby vs JRuby?

I wonder why GraalVM is not more often used for these speed critical cases: https://www.graalvm.org/python/

Is the problem the Oracle involvement? (Same for ruby https://www.graalvm.org/ruby/)

Looks like it’s still a WIP

https://github.com/oracle/truffleruby/commits?author=eregon

this comes at the cost of boxing ints inside Integer, though.

So, if you ignore for a moment primitives types, whenever you have generics, everything boils down to a single method accepting Objects and returning Objects. What the JVM does is to do runtime profiling of what actually you are passing to the generic method, and generate optimized routines for the "best case". In theory this is the best of the two worlds, because like in general you will have a single implementation of the method (avoiding duplication of the code), but if you use it in an hot spot you get the optimized code.

In a way, it is quite wasteful, because you throw away a lot of information at compile time, just to get it back (and maybe not all of it) at runtime through profiling, but in practice it works quite well.

A side effect of this is this makes the JVM a wonderful VM for running dynamic languages like Ruby and Python, because that information is _not_ there at compile time. In particular GraalVM/TruffleVM and exposes this functionality to dynamic language implementations, allowing very good performance (according to they website [1][2], Ruby and Python on TruffleVM are about 8x faster than the official implementation, and JS in line with V8)

[1] https://www.graalvm.org/ruby/

I opened a ticket some time ago about performance with Jekyll and liquid templates. At least in that case, yjit was way faster. I'm happy to retest though. Anything that would make my jekyll builds faster would help.

https://github.com/oracle/truffleruby/issues/2363

Here's a benchmark [1] done in Jan'22 against many ruby implementations, truffleRuby [2] seems to be way ahead in most, and at least ahead in all. Why truffleRuby isn't talk about much here?

[1] https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj...

[2] https://github.com/oracle/truffleruby

I would guess that depends on the licensing context in which it will be running, since Rhino is MPLv2 <https://github.com/mozilla/rhino/blob/Rhino1_7_14_Release/LI...> and OP's repo is MIT whereas Graal is UPLv1 <https://github.com/oracle/graaljs/blob/graal-23.1.2/LICENSE>. GitHub's license gizmo claims it is OSI/FSF approved, but Oracle gonna Oracle and they for sure have more lawyers than you do

graaljs

Here: https://github.com/oracle/graaljs

It's by Oracle: https://github.com/oracle/graaljs; seems to be built to interop w/ GraalVM based languages/services

If you need you can run JavaScript from within Java using Graal.js or Nashorn. To evaluate dynamic user input (Strings) you could also use a ScriptEngine (e.g. JavaScript) or dynamically compile inputs to Java using the JShell API.

That's just incredibly cool, my congratulations!

Foremost, my apologies if this is a nonsensical question. I haven't been soaking in the WASM ecosystem enough to know how much WASM is "just" JS versus ... something else.

Caveat aside, I saw one of the commits mention jython, which notoriously has ancient (and probably incredibly incomplete) python 2.x support; do you know if python-wasm would run on top of GraalJS (https://github.com/oracle/graaljs#nodejs-support)?

Separately, do you want issues related to zython.org in the cowasm issue tracker? It returns 405 (method not allowed) over and over on POST https://zython.org/python-wasm-sw/read-signal for me

Must be a fork because I found my own commits haha

https://github.com/oracle/graaljs/commits?author=styfle

Discussion reference https://github.com/oracle/graaljs/issues/239