I always wondered as TruffleRuby reached parity and pretty much has better performance characteristics in a broad standard set of use cases, why it doesn't have higher adoption. I've worked on Ruby applications with pretty decent user load and it was always the reference runtime, maybe a little jRuby for specific JVM reasons, but not Truffle.
If I was starting a project today, my reasons would be: If I don't need speed, why risk compatibility issues with Truffle. If I need speed, why use Ruby at all? (Or at least, why not Crystal which has other benefits)
Because it's a great language and very enjoyable to write code in.
Crystal is not quite Ruby even though it looks similar at a glance, it's far more static and a different development experience.
Faster and more parallel implementations of a language (TruffleRuby has no GVL) enable to use the language for more things. That's important, as we have seen e.g. with JavaScript and its fast runtimes.
What I meant is: the more I want something to be fast, the better defined it is, typically. So Ruby's good features matter less in that case. If I want to go really fast, I want to know exactly what's executing and the possibility that someone decided to extend Object in another way in some code path that now requires recompilation is not something I want to be thinking about. When running in parallel, I want to know about all the references and never run into some accidentally shared object.
Basically - I never felt the need to both have very high performance and sling bags of untyped strings around. And I think there's some general rule behind that that applies to many systems. Somehow emscripten and many other things in the ecosystem decided to go against the current with enough funding behind the runtime to make it possible. But I'm not sure it's a good thing that happened to JS.
"Needing speed" is not really that big general thing. Usually you want parts to be fast. Take your classic Ruby case, a Rails App. Maybe it's small and you really don't care. Maybe it's big (in terms of users or data) then you can often get away with your DB and your web server being fast, because your Rails App might essentially be just glue. But maybe some parts are not just glue, eg. rendering big complex template. You still don't want that to be slow. And if it's very big, maybe you don't want to waste resources by needing X percent more app servers.
But of course it's trade offs, just often not binary ones. This is similar to the "simplicity" discussion. As in you want your code to be simple and maintainable, but you might also have the code for a feature that simply requires a certain amount of complexity, but you still want to implement it being simple. In a similar manner, you might value things you get with Ruby higher than speed, but that doesn't mean you are willing to spend hours for something that could run in seconds.
And lastly a lot of things that Ruby offers aren't really bound to be slow, as Crystal impressively shows. But Crystal doesn't offer part of what Ruby and especially its ecosystem uses just yet.
I very much agree with "use the right tool for the job" and there are many many cases of where there will be better options. In a way that's the reason for a lot of FFI based Gems exist. Because Ruby might not be the right choice (eg. image encoding).
Our data backs up other findings that Ruby applications are generally less I/O-heavy, spending as much or more time on CPU as they do waiting on other services or database requests.
eg. rendering big complex template
That's something TruffleRuby is actually particularly good at.
One main use case is having a Ruby application/program and wanting to run it faster, TruffleRuby can help there.
We're also looking into running a subset of an application on TruffleRuby and the rest on CRuby, notably to be able to experiment more incrementally and speed up the part that needs it the most without affecting the rest.
kablamooo | a day ago
I always wondered as TruffleRuby reached parity and pretty much has better performance characteristics in a broad standard set of use cases, why it doesn't have higher adoption. I've worked on Ruby applications with pretty decent user load and it was always the reference runtime, maybe a little jRuby for specific JVM reasons, but not Truffle.
viraptor | a day ago
If I was starting a project today, my reasons would be: If I don't need speed, why risk compatibility issues with Truffle. If I need speed, why use Ruby at all? (Or at least, why not Crystal which has other benefits)
[OP] eregon | a day ago
Because it's a great language and very enjoyable to write code in.
Crystal is not quite Ruby even though it looks similar at a glance, it's far more static and a different development experience.
Faster and more parallel implementations of a language (TruffleRuby has no GVL) enable to use the language for more things. That's important, as we have seen e.g. with JavaScript and its fast runtimes.
viraptor | a day ago
What I meant is: the more I want something to be fast, the better defined it is, typically. So Ruby's good features matter less in that case. If I want to go really fast, I want to know exactly what's executing and the possibility that someone decided to extend Object in another way in some code path that now requires recompilation is not something I want to be thinking about. When running in parallel, I want to know about all the references and never run into some accidentally shared object.
Basically - I never felt the need to both have very high performance and sling bags of untyped strings around. And I think there's some general rule behind that that applies to many systems. Somehow emscripten and many other things in the ecosystem decided to go against the current with enough funding behind the runtime to make it possible. But I'm not sure it's a good thing that happened to JS.
reezer | 22 hours ago
"Needing speed" is not really that big general thing. Usually you want parts to be fast. Take your classic Ruby case, a Rails App. Maybe it's small and you really don't care. Maybe it's big (in terms of users or data) then you can often get away with your DB and your web server being fast, because your Rails App might essentially be just glue. But maybe some parts are not just glue, eg. rendering big complex template. You still don't want that to be slow. And if it's very big, maybe you don't want to waste resources by needing X percent more app servers.
But of course it's trade offs, just often not binary ones. This is similar to the "simplicity" discussion. As in you want your code to be simple and maintainable, but you might also have the code for a feature that simply requires a certain amount of complexity, but you still want to implement it being simple. In a similar manner, you might value things you get with Ruby higher than speed, but that doesn't mean you are willing to spend hours for something that could run in seconds.
And lastly a lot of things that Ruby offers aren't really bound to be slow, as Crystal impressively shows. But Crystal doesn't offer part of what Ruby and especially its ecosystem uses just yet.
I very much agree with "use the right tool for the job" and there are many many cases of where there will be better options. In a way that's the reason for a lot of FFI based Gems exist. Because Ruby might not be the right choice (eg. image encoding).
[OP] eregon | 22 hours ago
That seems rarely the case, see https://www.datadoghq.com/blog/ruby-performance-optimization/
That's something TruffleRuby is actually particularly good at.
One main use case is having a Ruby application/program and wanting to run it faster, TruffleRuby can help there. We're also looking into running a subset of an application on TruffleRuby and the rest on CRuby, notably to be able to experiment more incrementally and speed up the part that needs it the most without affecting the rest.
sardaukar | 19 hours ago
One reason might be that Oracle is behind it, and they'll sue you if you're too successful (see Java on Android)
[OP] eregon | 16 hours ago
Just to clarify: Oracle is no longer sponsoring TruffleRuby, and it’s developed independently now.
Also, Oracle doesn’t own Ruby or its spec, that’s maintained by the Ruby community, so this isn’t comparable to the Java/Android situation.
sardaukar | 16 hours ago
Isn't GraalVM the only way to run TruffleRuby? And isn't that developed by Oracle?
[OP] eregon | 16 hours ago
TruffleRuby can run on any JDK, not just GraalVM.
GraalVM also has an open-source Community Edition with contributions from multiple companies, so it’s not something Oracle exclusively controls.
In any case, using GraalVM or TruffleRuby doesn’t create anything like the Java/Android situation.