JRuby是否可以替代Rails开发的MRI？

Question

I am a beginner-verging-on-intermediate rails developer that is working hard to improve my skills.

I am a little confused about the state of JRuby, and whether it is a viable alternative to switch to from the MRI.

Currently I run a Mac at home and edit using textedit (MRI for ruby, terminal for rails commands, etc). At work, I use NetBeans on Windows, but don't do any Ruby work there.

I am seriously considering ditching the Mac for reasons irrelevant to this conversation, but I am worried that once I am on Windows, the support for Ruby will be less-than-optimal (I may be wrong about this).

I really enjoy working with Netbeans at work, and I can see that using JRuby on Windows with Netbeans and allowing JRuby to manage my gems would be a relatively pleasant experience. I like the idea of code completion and a full IDE rather than a text editor (without starting an editor flame war).

My question is, is JRuby going to complicate learning rails? From what I have seen, certain gems aren't supported on JRuby, or things might be done a little differently in that ecosystem. As a learner, I follow a lot of tutorials from the web and from books and I am worried that things might not work or will be hard to get working on JRuby. Is this scepticism well founded? Or should it be a relatively painless switch? How does it effect deployment onto non-JRuby platforms such as Heroku etc?

I am still weighing up a lot of options including MRI on Windows, MRI or JRuby on OpenSolaris, etc. I think that either way I will be going with Netbeans.

Any comments are appreciated.

Answer 1

Realistically you don't need code completion for Rails. TextMate is by far the most commonly used editor in the Ruby world, and it's more than sufficient for everything in Ruby. Ruby doesn't require anywhere near as much tool support as Java. So I would say that if the editor issue is the only reason you're opting for JRuby, it's not a very good reason. Because you're right, there are lots of gems that don't work in JRuby because they use a native extension of some kind. That said, the most popular gems tend to work in JRuby. Performance in JRuby still isn't quite as good as Ruby 1.9, but in a lot of cases it's comparable to MRI 1.8. Personally, I'd recommend treating JRuby as an advanced Ruby concept. It will run Rails, but yes, you're going to find that you won't be able to just follow along with a tutorial, and everything will be ever-so-slightly harder for a beginner. JRuby isn't a particular daunting piece of technology, but it might be more of a hurdle than you want to overcome as a beginner.

I highly recommend shelling out the Euros for a copy of TextMate anyways, even if you don't do your development in it primarily. It's worth every penny and then some. Work in that environment for awhile and see if you really need your IDE. I'm betting you won't.

Answer 2

My question is, is JRuby going to complicate learning rails?

Yes, because all the tutorials, beginner docs, and most of the devs who will normally be able to help you out are assuming MRI, so for each issue you have you must first eliminate a jRuby related cause.

From what I have seen, certain gems aren't supported on JRuby, or things might be done a little differently in that ecosystem.

Any gems that are written with C native extensions need to be ported to jRuby (the inverse is also true, but the issue is rarer).

As a learner, I follow a lot of tutorials from the web and from books and I am worried that things might not work or will be hard to get working on JRuby. Is this scepticism well founded?

I'd say yes, see my first point.

How does it effect deployment onto non-JRuby platforms such as Heroku etc?

The more your development environment strays from your production environment the more 'wacky' bugs will turn up. The alternative is to deploy to google app engine using jRuby.

On the other hand, who will write the jRuby tutorials if there is no demand?

Answer 3

I use Netbeans, Textmate, and Vim, but usually Netbeans. I love Netbeans's integrated debugging it is very helpful at times. Netbeans and Vim are cross platform and that is a big deal to me. I hate being dependent on software that is only available for one OS. I'm pretty sure I have tried just about every IDE for Rails, and Netbeans is the best Rails IDE in my oppionion, but I digress.

cwninja is right about JRuby's gem incompatibilities, albeit most gems are supported with JRuby. See http://isitjruby.com/ for supported gems. JRuby has a lot of momentum right now and is a strong development choice. In theory, choosing JRuby, or MRI should be inconsequential, but don't hold me to that. JRuby does allow to easily switch ruby compatibility between 1.8.x and 1.9.x pretty easily, but then again you could use RVM (which happens to be the bomb) to achieve this.

Either way, if you are considering using different ruby interpreters, take a look at RVM . It allows you to easily install and manage most ruby interpreters easily.

Answer 4

Look TBH moving away from a UNIX system towards a Windows system for Ruby developement, well it just seems stupid. Don't use a Mac if you don't want to, but a lot of stuff on Windows will just not work very well. You will spend more time screwing with stuff to get it working, than doing any work.

I recommend not using a code completing editor, it doesn't help you learn. I would say stay away from that till you have a good grounding in the language, learn where to look things up APIs etc before you start trying to shortcut things.

JRuby is definately a good alternative to MRI ruby, but if you are following tutorials it may just add the level of WTF as you learn that may well be counter productive, but if you do go to windows JRuby is probably the best way to go.

Good luck.

Answer 5

I started with MRI on OS X and then Windows. I use JRuby on Windows currently, but still fall back to MRI on Windows to check behavior, which is something you'll get used to. JRuby is undergoing a lot of changes to get it compatible with Ruby 1.9 and Ruby itself is somewhat of a moving target.

Looking at the differences between the two and reporting bugs though will ultimately strengthen your understanding of both, and will help both teams push the language forward.