3 ms·
I wonder how much this would change the performance of ruby... that's all kind of cool except no c extensions, that basically makes all the gems I use unusable.
by Exuma 7y ago
I wonder how much this would change the performance of ruby... that's all kind of cool except no c extensions, that basically makes all the gems I use unusable.
- dymk 7y agoThey'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.
- p4lindromica 7y agoHi, 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 https://github.com/artichoke/ferrocarril
- pmontra 7y agoJRuby doesn't support C extensions too https://github.com/jruby/jruby/wiki/C-Extension-Alternatives 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.