4 ms·

SVM is super cool, but there's a huge caveat: Not only is it closed source, but you can't even use things it outputs in production. The TruffleRuby wiki notes t

SVM is super cool, but there's a huge caveat: Not only is it closed source, but you can't even use things it outputs in production. The TruffleRuby wiki notes that the output of SVM is covered by http://www.oracle.com/technetwork/licenses/standard-license-152015.html http://www.oracle.com/technetwork/licenses/standard-license-... which says that you can only use it for testing and not production. Essentially, you can only get good startup times with TruffleRuby for testing. If you want to use TruffleRuby in production, you can't use the SVM version.

pmontra 10y ago
Big show stopper for now but I imagine they'll license the SVM once it's ready. Businesses will decide if it's worth the price. As a comparison, I never saw a small to medium Rails application running on Passenger Enterprise.
geodel 10y ago
I am sure there must be use cases where users need high performance and low RAM with Ruby, but can not move to Go/Rust/Java for critical parts and hence need something like SVM. I just can't think of those scenarios.
- nirvdrum 10y ago
  We're aiming to be 100% compatible with MRI. It's far easier to swap out your runtime than it is to rewrite production code. Of course, situations vary for everyone and each team needs to evaluate on their own. Prior to joining Oracle Labs, I ran a company that went through TechStars (Boston, 2010). We started with Ruby to get the MVP out. I would even say overall it was architected fairly well. But as we started growing, we hit performance issues that we just didn't have with a smaller customer base. As a bootstrapped company trying to grow, putting everything on hold to rewrite subsystems wasn't a terribly appealing option. We finally decided that it was a necessary evil and were going to move from MRI to JRuby, at which point we'd start replacing pieces with Java. As it turns out, JRuby ended up meeting our performance needs and we didn't have to rewrite anything (modulo code changes needed to run on JRuby). I ended up winding that company down for a variety of other reasons, but I'm happy I didn't become another case study in code rewrites.
  - geodel 10y ago
    Good to hear. At workplace we upgrade Java version without changing our code to use newer APIs. So far it is working reasonably well by getting benefit of newer GC and JRE without any code change.
deleted 10y ago
[deleted]

pmontra 10y ago

Big show stopper for now but I imagine they'll license the SVM once it's ready. Businesses will decide if it's worth the price. As a comparison, I never saw a small to medium Rails application running on Passenger Enterprise.

geodel 10y ago

I am sure there must be use cases where users need high performance and low RAM with Ruby, but can not move to Go/Rust/Java for critical parts and hence need something like SVM. I just can't think of those scenarios.

nirvdrum 10y ago
We're aiming to be 100% compatible with MRI. It's far easier to swap out your runtime than it is to rewrite production code. Of course, situations vary for everyone and each team needs to evaluate on their own. Prior to joining Oracle Labs, I ran a company that went through TechStars (Boston, 2010). We started with Ruby to get the MVP out. I would even say overall it was architected fairly well. But as we started growing, we hit performance issues that we just didn't have with a smaller customer base. As a bootstrapped company trying to grow, putting everything on hold to rewrite subsystems wasn't a terribly appealing option. We finally decided that it was a necessary evil and were going to move from MRI to JRuby, at which point we'd start replacing pieces with Java. As it turns out, JRuby ended up meeting our performance needs and we didn't have to rewrite anything (modulo code changes needed to run on JRuby). I ended up winding that company down for a variety of other reasons, but I'm happy I didn't become another case study in code rewrites.
- geodel 10y ago
  Good to hear. At workplace we upgrade Java version without changing our code to use newer APIs. So far it is working reasonably well by getting benefit of newer GC and JRE without any code change.

deleted 10y ago

[deleted]