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?
On Sat, Aug 15, 2009 at 10:45 PM, AlwaysCharging [email protected]
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? 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:
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
Good luck,
-Conrad
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
On Sun, Aug 16, 2009 at 7:29 AM, InventoryTrackers <
[email protected]> wrote:
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
-Conrad
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,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
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
On Sun, Aug 16, 2009 at 10:57 AM, Hassan
On Sun, Aug 16, 2009 at 7:29 AM,
InventoryTrackers[email protected] wrote:
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???
FWIW, ImageMagick with the mini_magick gem works fine with JRuby
(using attachment_fu).
–
Hassan S. ------------------------ [email protected]
twitter: @hassan
Marnen Laibow-Koser wrote:
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.
C’mon Marnen,
Don’t bash netbeans, especially 6.7. The differences from 6.5 to 6.7
are large. Since moving to 6.7, I have had very limited issues with
netbeans and rails. I made several other attempts at other IDEs and
even going with simple text editors. I came back to netbeans when 6.7
was released and have not looked back.
Also, I do not use JRuby so I agree with you on the fact that an IDE
shouldn’t determine which ruby version you use. NB supports multiple
platforms in multiple locations. You can remove JRuby from the list of
available platforms if you want to do so as well.
On Aug 16, 2009, at 4:18 PM, [email protected] wrote:
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?
Alpha B. wrote:
[…]
C’mon Marnen,
Don’t bash netbeans,
Why not? It doesn’t work well with Rails. I do not recommend it for
Rails work, and I make no apologies for that fact.
especially 6.7. The differences from 6.5 to 6.7
are large.
I believe my only experience with NetBeans was with 6.7, but I will make
sure of that. If I was in fact using 6.5, I will be happy to try 6.7.
Since moving to 6.7, I have had very limited issues with
netbeans and rails.
Me too. But I don’t want “very limited issues”. I want no avoidable
issues. I use and recommend a set of tools that achieves that goal.
NetBeans is not one of those tools.
I made several other attempts at other IDEs and
even going with simple text editors. I came back to netbeans when 6.7
was released and have not looked back.
Perhaps you’re using a different subset of Rails features than I am, and
NetBeans happens to support what you need (though even so, I still do
not believe that most IDEs are appropriate for Rails).
Also, I do not use JRuby so I agree with you on the fact that an IDE
shouldn’t determine which ruby version you use.
That’s a bad reason to agree with me. 
NB supports multiple
platforms in multiple locations. You can remove JRuby from the list of
available platforms if you want to do so as well.
Yup.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On Aug 16, 2009, at 6:51 PM, Maurício Linhares wrote:
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.
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…
On Sun, Aug 16, 2009 at 10:47 PM, s.ross[email protected] wrote:
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.
Maurício Linhares
http://codeshooter.wordpress.com/ | http://twitter.com/mauriciojr
Conrad T. 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,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On Aug 16, 2009, at 9:40 PM, Conrad T. wrote:
“huge” a win is multi-threading in the timespan of … say … <
It’s a huge win if you have blocking tasks. It’s not if you have tasks
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.
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.
takes you.
I have. It takes me into a painstaking exercise in protecting myself
against elusive and difficult to reproduce concurrency bugs.
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.
On Sun, Aug 16, 2009 at 10:36 PM, s.ross [email protected] wrote:
On Sun, Aug 16, 2009 at 10:47 PM, s.ross[email protected] wrote:
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.
it is in C-Ruby (i.e. MRI/YARV). Also, JRuby uses system native
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.
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.
takes you.
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
On Sun, Aug 16, 2009 at 7:07 PM, s.ross [email protected] wrote:
30ms?
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
On Aug 17, 5:40 am, Conrad T. [email protected] wrote:
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?
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
On Aug 16, 10:36 pm, “s.ross” [email protected] wrote:
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.
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
On Aug 16, 2009, at 11:53 PM, Conrad T. wrote:
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. [concurrency bugs, deadlocks, race conditions,
etc., – steve]
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.
On Aug 16, 7:55 am, Marnen Laibow-Koser <rails-mailing-l…@andreas-
s.net> wrote:
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.
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