Supported Ruby VMs

proposals
1

Hi all,
The scope of Lotus is huge and ambitious. We’re working only on volunteering time of all the great people around the framework.

What we achieved until now is remarkable, but to complete what’s in our roadmap in a decent time span, we need to narrow the scope of our effort.

We’re trying to open as much as possible the creation process of Lotus, involve new people to contribute to features. This is all great and inclusive, but it requires more effort from us and more time to get straight to the goal.

Me and @trung_le discussed to cut in the near future the Ruby VMs that we support. To maintain different Ruby versions with different implementations and features is becoming more and more unsustainable for us.

Sadly, Ruby is what MRI is. Other implementations will eventually follow. The problems are about the time that those maintainers will take to port MRI features into their alternative distributions.

It’s really far from me to criticize those teams. I can totally relate with them on how OSS is hard.
However, we just can’t wait for uncertain timelines.

With the release of MRI 2.2.0, they shipped a really important feature that solves a lot of problems for us: collectable symbols. Until that release, we didn’t had the chance of symbolize untrusted inputs. The risk was to expose applications to DoS attacks. So we had to put in place security mechanisms and at the same time offer convenient ways to access input via “indifferent access”.

To avoid symbols has a big perf impact for Lotus::Controller and Lotus::Validations. We aim for fast and secure applications, and now we can have both those qualities in Lotus if we support Ruby 2.2+.

Our proposal is to only support MRI 2.2+ and JRuby 9000. Those two VMs offer compatibility with Ruby 2.2 features.

We want to wait another month for JRuby to get out with a stable release and wait for MRI 2.2 wider adoption. Then we want to release a minor version of all the gems to mark the line with the past.

We’d love to hear your opinions. :heart:

2 Likes
2

Big :+1: on supporting only 2.2+ and latest jruby. Supporting more versions of MRI would result in a significant “waste” of time as Lotus is a new project that still needs months or even years to become feature-rich and stable full-stack webframework. By that time nobody will use anything lower than 2.2 (practically speaking). Even though there are still people maintaining apps on MRI 1.8.6 (no kidding) I don’t think it makes any sense to put so much effort into supporting older Rubies. With 2.x it’s even a simpler decision as moving from 2.0/2.1 to 2.2+ is not a big deal. So if somebody is “stuck” on 2.x and would like to use Lotus (which means there are good reasons to do so) then it would justify additional effort to upgrade to latest MRI.

At least that’s how I see it :smile:

2 Likes
3

I’m okay with that. There’s relatively little difference between any of the 2.x branches, as far as what’s executable. If it allows us to be faster, I’m okay pegging to 2.2 (heck, anything 2.1+ is fine from my perspective).

I think in terms of a longer-term strategy, supporting the latest three minor versions of both MRI and JRuby would be a very good way to strike a balance between keeping code modern and giving businesses time to upgrade their infrastructure. I can remember thinking when 2.2.0 came out ‘Wait, what? I just updated to 2.1…’, and a bit of a longer tail means that it’s easier for businesses to amortize the cost of staying near-current. I don’t think we need to start that now, but I would say it would be a good thing to continue post-2.2.

4

Besides Symbol GC, what are the other pain points in supporting Rubinius? Lack of compatibility with other Ruby 2.2+ features you use? The Rubinius team has always been willing to help as fast as we can, and personally I’d like to see Lotus run on Rubinius just like any of the other implementations.

5

For the time being, the only pain point is that Rubinius does not Symbol GC. And we learned that the support for this feature is uncertain. We love to get back to support rbx once rbx has caught up with MRI and JRuby.

6

Supported VMs

+------------+-------+-------------+--------+-------+------+------------+-------+
|            | Utils | Validations | Router | Model | View | Controller | Lotus |
+------------+-------+-------------+--------+-------+------+------------+-------+
| MRI 2.2    |   o   |      o      |    o   |   o   |   o  |      o     |   o   |
+------------+-------+-------------+--------+-------+------+------------+-------+
| MRI 2.1    |   o   |      o      |    o   |   o   |   o  |      o     |   o   |
+------------+-------+-------------+--------+-------+------+------------+-------+
| MRI 2.0    |   o   |      o      |    o   |   o   |   o  |      o     |   o   |
+------------+-------+-------------+--------+-------+------+------------+-------+
| JRuby 1.7+ |   o   |      o      |    o   |       |      |            |       |
+------------+-------+-------------+--------+-------+------+------------+-------+
| Rbx 2.3+   |   o   |      o      |        |       |      |            |       |
+------------+-------+-------------+--------+-------+------+------------+-------+

Router: Rbx VM quirks. I decided to drop the support because we were close to a release date
Model: Depends on Sequel, which causes CI failures w/ JRuby and Rbx
View: There always been CI failures w/ JRuby and Rbx
Controller: JRuby didn’t supported Module.prepend until now. Rbx CI didn’t passed in the past, and I haven’t checked recently.
Lotus: It depends on the previous gems. The support that it provides is the intersection of what described above.

In the past we hit corner cases that took time to debug and fix:

Sometimes those issues were blocking and we decided to drop support for a specific VM.
Sometimes they were trivial, but again, this is slowing down us.

MRI first

We’re using MRI as development tool and as a metric to check if a gem can be released.
I’ve personally always used it, just deployed one application with JRuby back in 2007.

We don’t have reliable stats, we’ve pinged Hampton Catlin to release the most recent results for his Ruby Survey. 1786 people replied for the 2014 edition:

  • MRI 93.849%
  • JRuby 3.894%
  • Rubinius 1.072%

When you have time constraint you want to apply the 80/20 rule.
I’m for technical diversity, but having to deal with uncertain timelines forces us to say no and move on. I’m sorry.

2.2 Mode

Why 2.2 mode is so important? We want safety first as a core value. Non-collectable symbols is a security threat. We can’t symbolize untrusted/unfiltered inputs. Bypassing this mechanism exposes applications to DoS attacks.
We need to use strings as keys and offer indifferent access, for developers convenience.

There is a GH issue with benchmarks that explains the current scenario.

In a nutshell: we had to give up an implementation (metaprogramming + symbols) that guaranteed 736.743k i/s in favor of one (string keys w/ indifferent access) that is really slower: 137.717k i/s.

Now that symbols are collectable, we can have both safe and fast applications.

Supported VMs

MRI already supports 2.2 mode and JRuby 9k preview1 is compliant with that mode. Their stable version should be out in a month. Even if they didn’t met deadlines in the past, there is something in sight.

We don’t want to keep Rubinius out for the sake of. We just don’t know when they will support this mode.

3 Likes
7

I have always worked with MRI and If I start a project I always start with the last Ruby.

Lotus is in a early phase and I think it doesn’t make sense support 2.0 and 2.1 ruby versions. I agree support jruby 9000 because in some companies use java JVM.

8

I’m going with MRI and JRuby too.
You said that

Model: Depends on Sequel, which causes CI failures w/ JRuby and Rbx
View: There always been CI failures w/ JRuby and Rbx

I don’t know well about those issues, so is it very hard to fix model and view to run in Jruby?

9

That would be part of our next effort. We hope it isn’t hard, because of Sequel and Tilt, which are dependencies to Model and View, respectively.

10

@jodosha I see, so what do you think of how should we approach this problem, should we replace the dependencies with Sequel and Tilt, or we will make a fork of those libraries and fix Jruby problem our self

11

No. Those libraries are battle tested after years of extensive usage in production. Do you think it would make sense for us to implement them from scratch?

If there will be some problems we can send patches to the maintainers. :wink:

12

Chicken, meet egg.

We’re discussing limiting support based on the concept that “Lotus is a new project that still needs months or even years to…”. The technical rationale is clear and fairly compelling; doing without the Ruby 2.2 features significantly increases the workload. And yet…

My shop is still stuck on Ruby 2.1.5 and expect to be on 2.1.x for most if not all of 2015 because numerous Gems we depend on simply don’t work correctly under MRI Ruby 2.2.0. Sure, systems like RVM, rbenv et al let us mix and match Ruby versions, but it’s still a detail people can (and in practice often do) get wrong or confuse when doing day-to-day work. This will discourage people from even playing with Lotus until most if not all of their other tools are 2.2-ready (by which time we’ll have the next great version with more great new features; all this has happened before, and…)

tl;dr I seriously question whether any “new project” that hopes to gain traction at a time of major, continuing language change can afford not to support current mainstream versions. It’s not like we’re talking about Ruby 1.9.3 (which we were all using just a few short months ago…).

13

@jdickey We’re here to discuss and listen :smile:

Which are the technical problems that prevent you to upgrade to Ruby 2.2? Which gems? Is there any dev ops problem? Please share your experience. Thank you.