They're going to have to spend an immense amount of time implementing all the performance optimizations present in mri/yarv bytecode engine before they achieve performance parity.

The amount of engineering effort to remove the GIL and simultaniously make C extensions work is probably not worth simply choosing a multi-process w/ shared memory solution for true parallelism.

Hi, I'm the author of Artichoke.

I wouldn't say all gems are unusable. I implemented a Rack-compatible application server in an early version of Artichoke that is capable of serving a Sinatra Rack app.

https://github.com/artichoke/ferrocarril

JRuby doesn't support C extensions too https://github.com/jruby/jruby/wiki/C-Extension-Alternatives

It's a parallel world in which developers either use pure Ruby gems or Java jars. For example, the database drivers are JDBC adapters straight from the Java world not the usual mysql2 or pg gems. Obviously the programs that use them are not portable unless there is a compatibility layer. In that example, ActiveRecord abstracts the drivers.

I don't know anything about Rust but maybe it could end up in the same way.