3 ms·
I wasn't in attendance but have watched many of the presentations and read quite a few accounts from those who were there and it seems like the implementation a
by dpeck 14y ago
I wasn't in attendance but have watched many of the presentations and read quite a few accounts from those who were there and it seems like the implementation are coming to quite a crossroads.
Those interested in doing anything "serious" seem to be doing it on jruby. Real threading seems to be a much requested/needed feature for many Ruby projects, but Matz has indicated quite clearly that he is not interested in removing the Global Interpreter Lock (GIL) from MRI ruby. Which is fine, as his he doesn't want the hard threading problems to be exposed to ruby coders.
Its kind of a shame that the jruby guys aren't a bigger part of the conversation on new features and the future of the language. But it is quite understandable when you look at the way ruby has been used in the past, and the direction that people are taking it in the future.
- jeremyjh 14y agoI'm not sure what gives you this idea. I've found jruby tool support lacking a bit - for example guard-spork doesnt work, guard-jruby has been broken for months. This tells me jruby is outside the mainstream, which matches other observations of the Gemfiles used in many projects which do not support jruby.
- dpeck 14y agoI'll agree that its outside the mainstream, but certainly less so than in the past. But I'll say that being outside the mainstream isn't necessarily a bad thing when so many gems rely on C extensions that tend to be flaky. Watching proceedings for any ruby conference a reoccurring theme is that people doing things that everyone is interested in tend to be doing it on the jruby implementation.