If you don't mine telling, were you a contractor or like a permanent dev? I'm very surprised that feds would choose Rails for projects. Maybe for prototypes or in house stuff or whatever.
Anyways, cool!
But, still very cool yeah!
Devs often complain about Java being boring and old-school, but it never ceases to amaze me how cool Java and Java-related techs are (JDK, JVM, GC etc.)!
Literally, state of the art, almost alien technology. And it seems that more cool stuff is coming.
Besides JRuby mentioned in TFA, there are awesome languages you can use like Scala, Clojure, Kotlin or even Haskell [0], all enabled by a runtime that proved to be truly multi-language, as in alternative languages are not just superficial syntactic sugar for Java (like CoffeeScript is for JS, or VB.NET is for C#).
Every time I have to use Java, the language, I hate it, however those languages are not Java, yet can leverage the decades of knowledge, libraries and tools built on top of the JVM.
It's a little funny in retrospective, I remember Microsoft's marketing in early 2000 and .NET developers were saying "Java is single language, multi-platform and .NET is multi-language, single-platform". Nowadays both statements are false.
And honestly, while well thought out and engineered, it hardly qualifies as almost alien technology.
The thesis it's based on points out there are no published papers covering exactly this technique, but are in fact two other production implementations that do basically the same thing (luajit and pypy) that exist.
That's usually a really good sign that what you've done is not that novel (in the sense of being straightforward to those in the world) even if it is really good engineering.
https://www.ruby-lang.org/en/news/2018/05/31/ruby-2-6-0-prev...
--
Some benchmarks ( 2017! )
https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch#mjit-...
- "Graal is too aggressive with compilations and almost always needs more CPU work than MRI interpreter"
- "JRuby and Graal are the worst with memory consumption"
- ...
Of course it's going to initially take more memory to just-in-time compile something than to just interpret it.
Most just-in-time compilers will also include an interpreter, so yes you get the same time and space needed to run to run the interpreter, and then you get extra time and space needed to run the compiler as well.
I don't really see why this would surprise anyone!
You just hope that over time it pays off when you get the faster code out of the end of it, which isn't something Makarov gave them a chance to do in this post. You'll notice that when he moves beyond running micro-benchmarks, and starts to run things like OptCarrot in later posts than this and with more reasonable time for warmup, he then sees the pay off of the more sophisticated just-in-time compilers.
> still the results are worse than the latest Graal Ruby
I’m so appreciative that we have an easy way to combine java code with ruby scripting, thanks Charles. You guys make my job possible. :D
I think particularly now that we have the excellent concurrent-ruby[0] project more developers should checkout jruby.
My suspicion is that the main pain point stopping people using jruby is around tooling and process forking.
The ruby tools I would normally use to get fast cycle times for things like running specs without restarting rails mostly rely seem to make use of forking which obviously isn't supported on the JVM.
If I can find more time and tallent that’s definitely something I look into.
I sort of hope that we, the rest of the community, could take care of that for you. Although faster start up would be awesome in general.
I don't know that we will really need to ever ship Graal; if you get OpenJDK 10+ you'll have it available. However we may at some point detect that Graal is available and turn it on for you. In the short term, the JAVA_OPTS env var is pretty simple to use, or just run on the community version of GraalVM that uses Graal JIT by default.
The activercord jdbc driver implementation is particularly problematic because it effectively keeps us from upgrading to Rails 5 (we use SQL Server as backend). There is also a lack of app server options. The Jruby app servers like Trinidad or Torquebox are not maintained. Warbler has issues, too.
Charles and the other devs can, of course, spend their time however they want, but from my perspective, having a well maintained software stack for production deployments is far more important than a further speed optimization.
SQL Server support still exists in our codebase but it has not been updated due to lack of resources. We want to continue to support it, but there's only three of us working on this stuff at all, and only two do this as our jobs!
As far as app servers...we recommend deploying like other Ruby folks do, using Puma as a server in multithreaded mode. Torquebox has unfortunately been put on hold because there are no resources to maintain it...but Puma works very well.
That said...the work we're doing to perform better on Graal will also speed things up on non-Graal JVMs: inlining more code, specializing data structures, reducing call overhead. You can rest assured things will continue to improve on Java 8 as well.
It sounds like you are trying to update to newer JVMs but running into problems, yes? I did a bunch of work about six months ago to support Java 9+ JVMs better, but I know there's more to do; the module system it introduce is tricky to work with/around.
