This year or maybe the next truffle ruby will be shipped. It already has a 9x performance boost over MRI and they are working really hard to ship c extensions support and lower startup times. So will you switch back to Rails for projects that need high performance backends.will rails gain the momentum again it had in 2009-10
JVM Ruby? Nope. If I need a high performance backend, I'd use Swift Perfect or Vapor before I'd use a JVM Ruby (some folks might prefer Rust/Go/etc, but it's the same idea.) You can even use Helix to write Ruby extensions in Rust if that's your thing. If I don't need a high performance (whatever that means) backend I'll stick with standard MRI.<p>Honestly the "performance" of Rails is rarely because of the Ruby speed but because of bad code choices (such as n+1 queries or just plan writing inefficient methods (retrieving entire objects when pluck might do, for example.)<p>If "high performance" is needed for specific parts of the application (such as processing and parsing large files,) then I'd just write a Swift microservice. I'd keep the ease of use of Rails overall but "outsource" the inneficient parts, assuming it would benefit the user experience.<p>My point: Ruby itself isn't really the bottleneck in most Rails codebases and JRuby and it's variants, in my past experience is just too painful to contemplate -- and rarely as necessary as people seem to think.<p>Just my opinion of course; I have been known to be wrong. ;)