ObjectSpace isn't really a major issue. JRuby disables (most of) it by default for performance reasons and I've never had to turn it on for any real code.

Ruby has been a major source of improvements in software, especially tooling and web development, over the last 10 years. A lot of the newer languages have borrowed concepts popularized by Ruby (gem-style package management; bundler-style dependency management; same-language build tools like rake; rails and sinatra-esque web frameworks). And a lot of tooling for other languages has been written in Ruby (sometimes later replaced by same-language tools). I'd compare the role Ruby has played to Perl in the '90s.

I certainly hope Ruby doesn't go down Perl's path. It may be protected from that fate by two differences. First, there's no Perl 6-like project to distract attention and effort from the actively used version. Second, Ruby remains by far the best general-purpose language out there for those of us who like Smalltalk-style OO languages (everything an object, message passing, extreme late binding).

I too would really like to see Swift escape the Apple ecosystem, for a number of reasons, even though I'm unlikely to use it myself.

Now I'm starting to wonder if it would be possible to adapt V8 directly to use other dynamically-typed scripting language, like the Parrot project was intended to do. A language parser at the front, V8 in the middle, and the language's standard library in the back.

Node.js demonstrated the power of V8 with an alternate stdlib, perhaps an alternate language in front is possible too? Then again, probably V8 is at the very least heavily entangled with Javascript's type-system.

Apple's FTL [1] is probably a better way to go. It's a high-level, general-purpose JIT for LLVM that is being used by Apple's own JavaScriptCore in WebKit. There was a discussion about it on HN a while back [2]

Last I checked, V8 was highly JS-specific, and you would have to rip out and replace large parts of it.

[1] https://trac.webkit.org/wiki/FTLJIT | https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-... | http://blog.llvm.org/2014/07/ftl-webkits-llvm-based-jit.html

[2] https://news.ycombinator.com/item?id=7740925

Ruby is a lot faster than it use to be. But it's a matter of Ruby being complimented by other languages for their best attributes.

Oh it's definitely faster than it used to be. It used to be really slow. But object instantiation is ultimately still very expensive, and in a language whose design encourages the creation of huge numbers of objects, that's a problem.

JRuby's really revived my love of Ruby. It's fast, it's powerful, and it's much easier to extend than CRuby. Jruby 9k and Truffle are both promising some pretty insane speedups, as well.

The JVM boot time is a bummer, but beyond that, there's not much to complain about.

Ruby is not inherently a slow language. An ideal setting, will be a Ruby open source compiler (similar with what RubyMotion does) that could be used to package your code. I would use the the interpreter to test/develop the code and the compiler to actually package it.

Exactly. People is on Ruby because of its semplicity to test ideas and craft things. That's the same reason so many devs started using Rails.

So, one immediate solution that would drive again Ruby to a stellar embracement and adoption could be preserving, in development, this immensely useful hyper-reflective environment which gives us hyper productivity and then have a parallel production environment where all of this is stripped down and code compiled without it.

In the wait for better solutions this could be a possible path, and I am sure a lot of people and software in the Ruby ecosystem would still prefer to adapt to this, rather than having to code in a more performant but ugly language.