# JRuby vs Ruby: why would you ever use ruby? **URL:** \ **Category:** rubyonrails-talk\ **Created:** [August 16, 2009, 5:45am UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202 "2009-08-16T05:45:53Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![AlwaysCharging](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@AlwaysCharging](https://discuss.rubyonrails.org/u/AlwaysCharging)\ **Post date:** [August 16, 2009, 5:45am UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/1 "2009-08-16T05:45:53Z")
Why would anyone use ruby over Jruby? I'm admittedly a noob about all this stuff, but from what I've read jruby seems superior to ruby and quite a bit faster. What would be the disadvantages of JRuby? I man it's possible to use it with rails now, and JRuby is what's used by default in netbeans (which is the ide I think I've settled on). So why not JRuby? Would the tutorials be all that different? ---
**Author:** ![Con](https://avatars.discourse-cdn.com/v4/letter/c/9fc29f/32.png) [@Con](https://discuss.rubyonrails.org/u/Con)\ **Post date:** [August 16, 2009, 9:35am UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/2 "2009-08-16T09:35:27Z")
> Why would anyone use ruby over Jruby? I’m admittedly a noob about all > > this stuff, but from what I’ve read jruby seems superior to ruby and > > quite a bit faster. What would be the disadvantages of JRuby? I man > > it’s possible to use it with rails now, and JRuby is what’s used by > > default in netbeans (which is the ide I think I’ve settled on). So > > why not JRuby? Would the tutorials be all that different? You’re pretty much free to use any implementation of Ruby for your project. Also, it really come down to what are your underlying project requirements. So, why would anyone use Ruby over JRuby? o dictated by the company o existing part of current IT infrastructure o has support for many of the Ruby 3rd party libraries/frameworks/plugins o developing Ruby C extensions So, why would anyone use JRuby over Ruby? o very good performing JVM and much faster than Ruby 1.8.6 (.i.e MRI) and is on par with Ruby 1.9.1 (i.e YARV) in a lot of the tests that I have seen online o allows me to access some very popular Java libraries from Ruby o supports both Ruby 1.8.6 and Ruby 1.9 language specifications o has very good support for Rails today o has very good support for Google App Engine today o can use a multitude of web server configurations both Java and non-Java o has support for true multi-threading because the Global Interpreter Lock (GIL) doesn’t exist I’m sure that there are many more pros for selecting Ruby over JRuby and vice-versa but you should be able to get the picture. Please take a look at the following links for additional information: [http://www.infoq.com/interviews/charles-nutter-jruby](http://www.infoq.com/interviews/charles-nutter-jruby) [http://www.jruby.com](http://www.jruby.com) You might want to also ask your question on the following list which is dedicated to the JRuby community: [http://groups.google.com/group/jruby-users](http://groups.google.com/group/jruby-users) Good luck, -Conrad ---
**Author:** ![InventoryTrackers](https://avatars.discourse-cdn.com/v4/letter/i/59ef9b/32.png) [@InventoryTrackers](https://discuss.rubyonrails.org/u/InventoryTrackers)\ **Post date:** [August 16, 2009, 2:29pm UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/3 "2009-08-16T14:29:34Z")
My two cents. None of the RMagick stuff with attachment\_fu would work when I tried to use JRuby. They said they had something like JMagick? but nobody I contacted seemed to use photos in their application??? David ---
**Author:** ![11175](https://avatars.discourse-cdn.com/v4/letter/1/8edcca/32.png) [@11175](https://discuss.rubyonrails.org/u/11175)\ **Post date:** [August 16, 2009, 2:55pm UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/4 "2009-08-16T14:55:40Z")
AlwaysCharging wrote: > Why would anyone use ruby over Jruby? I'm admittedly a noob about all this stuff, but from what I've read jruby seems superior to ruby and quite a bit faster. What would be the disadvantages of JRuby? It's Java. This is both an advantage and a disadvantage: you already know about the advantages, but server-side Java can be hard to set up for Web stuff. Personally, I'm using Ruby Enterprise Edition on many of my servers, which gives better performance but without the hassle of JRuby. > I man it's possible to use it with rails now, and JRuby is what's used by default in netbeans (which is the ide I think I've settled on). That is a bad reason to pick JRuby. Anyway, you probably shouldn't be using Netbeans: it's a good IDE, but not for Rails. It's stupid enough not to pick up generators properly, and in my experience, it doesn't integrate all that well with Rails anyway, although I may try it again in a year or two. Anyway, I would urge you (especially at first) not to use an IDE for Rails. IDEs are great for heavy Java frameworks where there are lots of config files to automatically generate, but I do not believe they are necessary -- or even desirable -- for Rails. Use a good editor such as KomodoEdit (my current choice), TextMate, or jEdit and a bunch of terminal windows. If you use an IDE for Rails you'll actually be making your life harder. > So why not JRuby? Would the tutorials be all that different? As far as the language is concerned, no. As far as Web server setup is concerned, yes, very much. Note: the server setup can actually be an advantage if you already have a Java setup that you want to integrate with. I don't, so I'd rather not deal with Java servlet containers. Best, ---
**Author:** ![Con](https://avatars.discourse-cdn.com/v4/letter/c/9fc29f/32.png) [@Con](https://discuss.rubyonrails.org/u/Con)\ **Post date:** [August 16, 2009, 2:57pm UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/5 "2009-08-16T14:57:01Z")
> My two cents. > > None of the RMagick stuff with attachment\_fu would work when I tried > > to use JRuby. They said they had something like JMagick? but nobody I > > contacted seemed to use photos in their application??? > > David David, have you posted to the JRuby mailing list in regards to RMagick or support for the Ruby C-Extensions? Also, you can find some additional limitations with JRuby here: [http://jruby.codehaus.org/Limitations](http://jruby.codehaus.org/Limitations) -Conrad ---
**Author:** ![hassan](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/hassan/32/714_2.png) [@hassan](https://discuss.rubyonrails.org/u/hassan)\ **Post date:** [August 16, 2009, 2:57pm UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/6 "2009-08-16T14:57:29Z")
FWIW, ImageMagick with the mini\_magick gem works fine with JRuby (using attachment\_fu). ---
**Author:** ![AD13](https://avatars.discourse-cdn.com/v4/letter/a/bbe5ce/32.png) [@AD13](https://discuss.rubyonrails.org/u/AD13)\ **Post date:** [August 16, 2009, 11:18pm UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/7 "2009-08-16T23:18:14Z")
I would say native multi-threading is a huge plus for Jruby as well. For image processing I believe image-vodoo has been had with much success in the Jruby world (as well as attachment\_fu and rmagick) One negative for Jruby is if you want to use a gem with a native-C only extension then you are out of luck, but most so far I have seen have had C and Jave implementations of the gem. AD ---
**Author:** ![Steve\_Ross](https://avatars.discourse-cdn.com/v4/letter/s/3d9bf3/32.png) [@Steve\_Ross](https://discuss.rubyonrails.org/u/Steve_Ross)\ **Post date:** [August 17, 2009, 1:47am UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/8 "2009-08-17T01:47:25Z")
> I would say native multi-threading is a huge plus for Jruby as well. Why do you say this? Most request/response cycles are so quick that they are unlikely to benefit significantly from multithreading. How "huge" a win is multi-threading in the timespan of ... say ... \< 30ms? ---
**Author:** ![Mauricio\_Linhares](https://avatars.discourse-cdn.com/v4/letter/m/b5a626/32.png) [@Mauricio\_Linhares](https://discuss.rubyonrails.org/u/Mauricio_Linhares)\ **Post date:** [August 17, 2009, 1:51am UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/9 "2009-08-17T01:51:27Z")
It's a HUGE win 'cos if you have a machine with multiple processing cores (something that's as common as a keyboard and a mouse nowadays) your server can benefit from them without a separate process and all the monitoring/memory/OS footprint that this solution carries. ---
**Author:** ![Steve\_Ross](https://avatars.discourse-cdn.com/v4/letter/s/3d9bf3/32.png) [@Steve\_Ross](https://discuss.rubyonrails.org/u/Steve_Ross)\ **Post date:** [August 17, 2009, 2:07am UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/10 "2009-08-17T02:07:57Z")
It's a huge win if you have blocking tasks. It's not if you have tasks that cannot be parallelized. My point is that a good deal of the stuff you do between when you get a request and when you serve a response is done in a linear manner. If you were going out and foraging among several Web services to create a composite response then fine, multithread away. Multithreading is just peachy for systems where orthogonal bodies of work can be isolated into threads and run at their own pace and/or block on external dependencies like IO, to coalesce when possible. For example, finding and formatting a bunch of data and populating a listbox in a client app without freezing the UI. But such orthogonality is seldom, in my experience, found in that brief instant between a user request and the time the response must be issued. So my question is still: How much of a practical (not theoretical) win is MT for a Web application and does the J in JRuby really increase the win over green threads for this brief a set of tasks? Just asking... ---
**Author:** ![Con](https://avatars.discourse-cdn.com/v4/letter/c/9fc29f/32.png) [@Con](https://discuss.rubyonrails.org/u/Con)\ **Post date:** [August 17, 2009, 4:40am UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/11 "2009-08-17T04:40:52Z")
> > > > > > > > > > Why do you say this? Most request/response cycles are so quick that > > > > they are unlikely to benefit significantly from multithreading. How > > > > “huge” a win is multi-threading in the timespan of … say … \< > > > > 30ms? > > > > > > > > > > It’s a HUGE win 'cos if you have a machine with multiple processing > > > cores (something that’s as common as a keyboard and a mouse nowadays) > > > your server can benefit from them without a separate process and all > > > the monitoring/memory/OS footprint that this solution carries. > > > > It’s a huge win if you have blocking tasks. It’s not if you have tasks > > that cannot be parallelized. My point is that a good deal of the stuff > > you do between when you get a request and when you serve a response is > > done in a linear manner. If you were going out and foraging among > > several Web services to create a composite response then fine, > > multithread away. I can have long running tasks that does not block. I can stuff it in a thread, return to the caller, and wait for a notification. This can be done using a single thread and no additional plugins. In C-Ruby, the way to work around the GIL to achieve concurrency is to push this functionality down into the Ruby C-Extension. Thus, you’ll be using processes for thread parallelism. This workaround isn’t needed with JRuby. JRuby provides a threading model which allows one to write truly concurrent Rails applications because it’s not limited by a GIL as it is in C-Ruby (i.e. MRI/YARV). Also, JRuby uses system native threads that operate concurrently instead of green threads. Next, I have seen better resource utilization by using VMs that support multiple cores. What’s the point of having an 8 core machine and 10 mongrels running on a single core? > Multithreading is just peachy for systems where orthogonal bodies of > > work can be isolated into threads and run at their own pace and/or > > block on external dependencies like IO, to coalesce when possible. For > > example, finding and formatting a bunch of data and populating a > > listbox in a client app without freezing the UI. But such > > orthogonality is seldom, in my experience, found in that brief instant > > between a user request and the time the response must be issued. You should try writing a multi-threaded Rails application and see where it takes you. > So my question is still: How much of a practical (not theoretical) win > > is MT for a Web application and does the J in JRuby really increase > > the win over green threads for this brief a set of tasks? In short, JRuby opens the door to accessing the wealth of Java libraries and frameworks. Also, it provides a truly current threading model using system native threads and I’m glad that there are other implementations leveraging the environments that are used to build them. -Conrad ---
**Author:** ![11175](https://avatars.discourse-cdn.com/v4/letter/1/8edcca/32.png) [@11175](https://discuss.rubyonrails.org/u/11175)\ **Post date:** [August 17, 2009, 4:57am UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/12 "2009-08-17T04:57:55Z")
Conrad Taylor wrote: [some very good stuff about threads] > You should try writing a multi-threaded Rails application and see where it takes you. Surely this is putting the cart before the horse. Except for toy proof-of-concept apps, if I wind up with a multithreaded Rails app, it won't be because I set out to write a multithreaded Rails app. Rather, it will be because I set out to implement some functionality, and that functionality requires multiple threads. [...] > In short, JRuby opens the door to accessing the wealth of Java libraries and frameworks. Thanks, but no thanks. If I wanted that, I'd just use Java. (There are perhaps a couple of exceptions to that response, thoughm) > Also, it provides a truly current threading model using system native threads and I'm glad that there are other implementations leveraging the environments that are used to build them. As am I. But like Steve, I'm not convinced that this means a heck of a lot for many Rails apps. (For some, though, it will mean a lot, to be sure.) > -Conrad Best, ---
**Author:** ![Steve\_Ross](https://avatars.discourse-cdn.com/v4/letter/s/3d9bf3/32.png) [@Steve\_Ross](https://discuss.rubyonrails.org/u/Steve_Ross)\ **Post date:** [August 17, 2009, 5:36am UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/13 "2009-08-17T05:36:18Z")
> \> \>\> \>\> Why do you say this? Most request/response cycles are so quick that \>\> they are unlikely to benefit significantly from multithreading. How \>\> "huge" a win is multi-threading in the timespan of ... say ... \< \>\> 30ms? \>\> \> \> It's a HUGE win 'cos if you have a machine with multiple processing \> cores (something that's as common as a keyboard and a mouse nowadays) \> your server can benefit from them without a separate process and all \> the monitoring/memory/OS footprint that this solution carries. \> > > It's a huge win if you have blocking tasks. It's not if you have tasks that cannot be parallelized. My point is that a good deal of the stuff you do between when you get a request and when you serve a response is done in a linear manner. If you were going out and foraging among several Web services to create a composite response then fine, multithread away. > > I can have long running tasks that does not block. I can stuff it in a thread, return to the caller, and wait for a notification. This can be done using a single thread and no additional plugins. And the common everyday Rails applicability of being able to stuff a long-running task into a thread is what I've seldom seen. > In C-Ruby, the way to work around the GIL to achieve concurrency is to push this functionality down into the Ruby C-Extension. Thus, you'll be using processes for thread parallelism. This workaround isn't needed with JRuby. JRuby provides a threading model which allows one to write truly concurrent Rails applications because it's not limited by a GIL as it is in C-Ruby (i.e. MRI/YARV). Also, JRuby uses system native threads that operate concurrently instead of green threads. I understand the difference between the OS-native threads and Ruby's threads that run under the GIL. Multi-processing is, however, not the worst solution. Consider this: There is no standard IPC for the threaded model because threads run (duh) in-process. So how do threads communicate? Shared (global?) variables. So now you are facing concurrency problems, setting and releasing mutexes, and all the other keen stuff you don't have to do if you use the more constrained multi-process model. > Next, I have seen better resource utilization by using VMs that support multiple cores. What's the point of having an 8 core machine and 10 mongrels running on a single core? That's like saying why have a car that can go 150 when the speed limit is 65? Having multiple cores is not a reason in and of itself to design multithreaded solutions. Some problems are well-suited to parallel solutions; some aren't. But the problem is not defined by the target architecture. > Multithreading is just peachy for systems where orthogonal bodies of work can be isolated into threads and run at their own pace and/or block on external dependencies like IO, to coalesce when possible. For example, finding and formatting a bunch of data and populating a listbox in a client app without freezing the UI. But such orthogonality is seldom, in my experience, found in that brief instant between a user request and the time the response must be issued. > > You should try writing a multi-threaded Rails application and see where it takes you. I have. It takes me into a painstaking exercise in protecting myself against elusive and difficult to reproduce concurrency bugs. > So my question is still: How much of a practical (not theoretical) win is MT for a Web application and does the J in JRuby really increase the win over green threads for this brief a set of tasks? > > In short, JRuby opens the door to accessing the wealth of Java libraries and frameworks. Also, it provides a truly current threading model using system native threads and I'm glad that there are other implementations leveraging the environments that are used to build them. I'm really not missing Java that much. I think multi-threading is just another arrow in the quiver of the good software designer. Having been down this road many times, I find it difficult to characterize multi-threading as a "huge win" in the context of Web applications. ---
**Author:** ![Con](https://avatars.discourse-cdn.com/v4/letter/c/9fc29f/32.png) [@Con](https://discuss.rubyonrails.org/u/Con)\ **Post date:** [August 17, 2009, 6:53am UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/14 "2009-08-17T06:53:52Z")
> > > > > > > > > > > > > > > > > > > > > > Why do you say this? Most request/response cycles are so quick that > > > > > they are unlikely to benefit significantly from multithreading. How > > > > > “huge” a win is multi-threading in the timespan of … say … \< > > > > > 30ms? > > > > > > > > > > > > > It’s a HUGE win 'cos if you have a machine with multiple processing > > > > cores (something that’s as common as a keyboard and a mouse > > > nowadays) > > > > your server can benefit from them without a separate process and all > > > > the monitoring/memory/OS footprint that this solution carries. > > > > > > > > > > It’s a huge win if you have blocking tasks. It’s not if you have tasks > > > that cannot be parallelized. My point is that a good deal of the stuff > > > you do between when you get a request and when you serve a response is > > > done in a linear manner. If you were going out and foraging among > > > several Web services to create a composite response then fine, > > > multithread away. The things that happen between a request and response do not need to be done in a linear manner. This is your choice and you may be constrained to do this for many reasons. Also, you might have a well defined workflow which dictates when, where, and how information is to be processed. > > > > > I can have long running tasks that does not block. I can stuff it > > > in a thread, > > > return to the caller, and wait for a notification. This can be done > > > using a > > > single thread and no additional plugins. > And the common everyday Rails applicability of being able to stuff a > > long-running task into a thread is what I’ve seldom seen. Yes, this is true of the common everyday application. However, others are doing innovative and difference things with the Ruby language in addition to Rails. > > In C-Ruby, the way to work around the GIL to achieve concurrency is to > > > push this functionality down into the Ruby C-Extension. Thus, > > > you’ll be > > > using processes for thread parallelism. This workaround isn’t > > > needed with > > > JRuby. JRuby provides a threading model which allows one to write > > > truly > > > concurrent Rails applications because it’s not limited by a GIL as > > > it is in C-Ruby (i.e. MRI/YARV). Also, JRuby uses system native > > > threads > > > that operate concurrently instead of green threads. > I understand the difference between the OS-native threads and Ruby’s > > threads that run under the GIL. Multi-processing is, however, not the > > worst solution. Consider this: There is no standard IPC for the > > threaded model because threads run (duh) in-process. So how do threads > > communicate? Shared (global?) variables. So now you are facing > > concurrency problems, setting and releasing mutexes, and all the other > > keen stuff you don’t have to do if you use the more constrained multi- > > process model. I can safely safe after playing with Grand Central Dispatch for 2.5 months, it’s the way to go for doing MT which alleviates most of the problems that you mention above. > > Next, I have seen better resource utilization by using VMs that > > > support multiple cores. What’s the point of having an 8 core > > > machine and > > > 10 mongrels running on a single core? > That’s like saying why have a car that can go 150 when the speed limit > > is 65? Having multiple cores is not a reason in and of itself to > > design multithreaded solutions. Some problems are well-suited to > > parallel solutions; some aren’t. But the problem is not defined by the > > target architecture. I’m simply sayint that one shouldn’t waste resources. Yes, I agree with you that having multiple cores isn’t the reason for MT but having the ability to distribute load across cores is better than wasting cores or buying additional hardware that’s not needed. Yes, the problem isn’t defined by the target architecture but the solution is defined by the target architecture. This is very consistent within software development in understanding your risk analysis in the design phase of your project. > > Multithreading is just peachy for systems where orthogonal bodies of > > > work can be isolated into threads and run at their own pace and/or > > > block on external dependencies like IO, to coalesce when possible. For > > > example, finding and formatting a bunch of data and populating a > > > listbox in a client app without freezing the UI. But such > > > orthogonality is seldom, in my experience, found in that brief instant > > > between a user request and the time the response must be issued. > > > > > > You should try writing a multi-threaded Rails application and see > > > where it > > > takes you. > I have. It takes me into a painstaking exercise in protecting myself > > against elusive and difficult to reproduce concurrency bugs. > > > So my question is still: How much of a practical (not theoretical) win > > > is MT for a Web application and does the J in JRuby really increase > > > the win over green threads for this brief a set of tasks? > > > > > > In short, JRuby opens the door to accessing the wealth of Java > > > libraries > > > and frameworks. Also, it provides a truly current threading model > > > using > > > system native threads and I’m glad that there are other > > > implementations > > > leveraging the environments that are used to build them. > I’m really not missing Java that much. I’m not a huge fan of Java but JRuby is simply another option within the Ruby landscape. You can take it or leave it. > I think multi-threading is just another arrow in the quiver of the > > good software designer. Having been down this road many times, I find > > it difficult to characterize multi-threading as a “huge win” in the > > context of Web applications. MT is generally a hard topic but GCD is making it very easy these days. -Conrad ---
**Author:** ![Steve\_Ross](https://avatars.discourse-cdn.com/v4/letter/s/3d9bf3/32.png) [@Steve\_Ross](https://discuss.rubyonrails.org/u/Steve_Ross)\ **Post date:** [August 17, 2009, 5:17pm UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/15 "2009-08-17T17:17:46Z")
GCD is incredibly exciting. Yes, this really got me going too. But it's of so much more direct value to Cocoa apps than Web apps -- unless you intend to deploy on a Mac SL Server. If GCD lives up to its potential, things like Photoshop and Lightroom might get downright snappy. But unless it can be backported to Linux, the general applicability for most Web deployments is questionable. I \*am\* a fan of parallel processing. Works like a charm for certain tasks where the load can be effectively distributed and that includes pretty much every client app that needs to keep a UI active and responsive while drawing stuff on the screen or interacting with persistent data. Web apps... well, Apache has the MPM model that distributes across any cores that are available, and many use load-balancing proxies to run a pack of mongrels. Mongrel itself can distribute some of its processing, as some of it is native. We'll see if MT makes a big impact on Rails development as a result of the Snow Leopard release. ---
**Author:** ![Frederick\_Cheung](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/frederick_cheung/32/3901_2.png) [@Frederick\_Cheung](https://discuss.rubyonrails.org/u/Frederick_Cheung)\ **Post date:** [August 17, 2009, 5:24pm UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/16 "2009-08-17T17:24:34Z")
except that each mongrel is a separate process and so they will get spread across multiple cores (not to say that ruby 1.8's threading don't suck and of course you'll save memory by having 1 ten threaded instance rather than 10 1 threaded instances). Fred ---
**Author:** ![Charles\_Nutter](https://avatars.discourse-cdn.com/v4/letter/c/eb9ed0/32.png) [@Charles\_Nutter](https://discuss.rubyonrails.org/u/Charles_Nutter)\ **Post date:** [August 18, 2009, 7:43pm UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/17 "2009-08-18T19:43:50Z")
If you want to use attachment\_fu, you can look at image\_voodoo, a JRuby version of image\_science...I think that gives you everything you need. The RMagick-lookalike project is rmagick4j. It has enough implemented to pass all of Gruff Graph's tests, which is pretty good. But it's not 100%. - Charlie ---
**Author:** ![Charles\_Nutter](https://avatars.discourse-cdn.com/v4/letter/c/eb9ed0/32.png) [@Charles\_Nutter](https://discuss.rubyonrails.org/u/Charles_Nutter)\ **Post date:** [August 18, 2009, 7:49pm UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/18 "2009-08-18T19:49:04Z")
> It's Java. This is both an advantage and a disadvantage: you already know about the advantages, but server-side Java can be hard to set up for Web stuff. Personally, I'm using Ruby Enterprise Edition on many of my servers, which gives better performance but without the hassle of JRuby. JRuby works fine as a Mongrel process (and if you turn on threadsafe mode in Rails, your entire site can be a \*single\* process). There's also the glassfish gem, which allows one-command deployment of an entire app, all in a single process. I think the difficulty of setting up JRuby on the server has been vastly overstated. $ gem install glassfish $ glassfish -e production \ That's it. > **[Apache + JRuby + Rails + GlassFish = Easy Deployment!](http://blog.headius.com/2009/04/apache-jruby-rails-glassfish-easy.html)** > > It occurred to me today that a lot of people probably want a JRuby deployment option that works with a front-end web server. I present for you the trivial steps required to host a JRuby server behind Apache.Update: It's worth mentioning that this... > \> I man \> it's possible to use it with rails now, and JRuby is what's used by \> default in netbeans (which is the ide I think I've settled on). > > That is a bad reason to pick JRuby. Anyway, you probably shouldn't be using Netbeans: it's a good IDE, but not for Rails. It's stupid enough not to pick up generators properly, and in my experience, it doesn't integrate all that well with Rails anyway, although I may try it again in a year or two. There's actually a number of people that like NetBeans (or one of the other IDEs) a lot for Rails work. And of course if you're working with several languages, it does a very good job. > Anyway, I would urge you (especially at first) not to use an IDE for Rails. IDEs are great for heavy Java frameworks where there are lots of config files to automatically generate, but I do not believe they are necessary -- or even desirable -- for Rails. Use a good editor such as KomodoEdit (my current choice), TextMate, or jEdit and a bunch of terminal windows. If you use an IDE for Rails you'll actually be making your life harder. I don't think that's true. But it's a matter of opinion. Even if you don't use those IDEs as anything more than editors, they're very nice editors. > As far as the language is concerned, no. As far as Web server setup is concerned, yes, very much. > > Note: the server setup can actually be an advantage if you already have a Java setup that you want to integrate with. I don't, so I'd rather not deal with Java servlet containers. You don't have to deploy to a Java servlet container, and for typical Rubyists we actually recommend using one of the non-servlet options. - Charlie ---
**Author:** ![Charles\_Nutter](https://avatars.discourse-cdn.com/v4/letter/c/eb9ed0/32.png) [@Charles\_Nutter](https://discuss.rubyonrails.org/u/Charles_Nutter)\ **Post date:** [August 18, 2009, 7:59pm UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/19 "2009-08-18T19:59:44Z")
I'll go a little bit controversial now: the fact that typical Rails deployments have to spin up multiple processes is totally mickey- mouse. What decade is this? With JRuby, just by avoiding the use of globally-accessible variables (globals, class variables) you can run an entire site with a single Rails instance in a single process. We've had reports from people running on 16-core boxes with JRuby in a single 100-200MB process, handling \*thousands\* of end-to-end requests per second. How many Mongrels or REE processes would you need to do that? At least 16 to make use of all the cores, and more if you don't want cores to sit idle half the time while blocking on IO. Multithreading in JRuby doesn't mean you need to write multi-threaded Rails apps; it means you get to take advantage of Rails thread-safe mode (2.2+) to shove as many requests as you possibly can through a single instance. No other Ruby implementation can do that. - Charlie ---
**Author:** ![pharrington](https://avatars.discourse-cdn.com/v4/letter/p/e95f7d/32.png) [@pharrington](https://discuss.rubyonrails.org/u/pharrington)\ **Post date:** [August 18, 2009, 8:58pm UTC](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202/20 "2009-08-18T20:58:38Z")
What prevents this from working properly in Ruby 1.9? [Next page](https://discuss.rubyonrails.org/t/jruby-vs-ruby-why-would-you-ever-use-ruby/45202.md?page=2)