

The future of Ruby is....Java? - ohhmaagawd
http://blog.headius.com/2009/07/jrubys-importance-to-ruby-and-erubycon.html

======
rs
Not intending to start a flamewar with VM/Intepreter implementations, BUT I
have to agree with the article.

When I was evaluating on platforms for a rewrite of xp-dev.com, I did
seriously consider using RoR with JRuby, but there was some parts missing here
and there (including some bugs) that it was just not worth the risk for the
scale of the project.

I ended up going back to a Java web framework, thinking, I'll keep a close eye
on JRuby and see if it can be used in future projects.

The JVM is an excellent VM - things like having the ability to set heap sizes,
JMX and all the readily available sugar that comes from it is well worth
trying to support as many languages into it, and for that reason, Ruby needs
the JVM. Re-implementing things like JIT, GC is just not worth the trouble.
Ruby hackers can actually focus on real, hard productive features and
essential bug fixes which would be a better use of their precious time.

* JVM here refers to Sun's JVM implementation, not the spec. JRockit is pretty good as well.

~~~
michaelneale
>things like having the ability to set heap sizes

Oh that has always irritated me, and others - having to know what to set it to
up front - interesting that you like it?

~~~
rs
I don't think it's "having to know what to set it to up front" - its more
experimentation and seeing what has the best performance. Too big heap and
poor code, you might end up having really, really long GC pauses. Too small
heap and you'll be out of heap space.

I like it as there's only so much physical memory on a server, and there's
only so much virtual memory a kernel can provide. Swapping is not a good idea
if you're looking into performance, and hence limiting the heap size can turn
out to be a good strategy to ensure that your application does perform within
expected boundries.

------
zmimon
If Charles really believes this then he needs to assign a bit more priority to
some of bugs / feature requests that revolve around java integration. I
wouldn't mind using JRuby to replace various java oriented tasks but the lack
of various features such as full support for annotations makes it impossible.

He's definitely right about one thing though - JRuby has to some extent missed
the bus here - Groovy now does just about everything I need and it would now
be a big sell to win me back to using JRuby (which was not true 1 or 2 years
ago).

------
donw
I'm honestly really thrilled with all the choices on the JVM; not just JRuby,
but Java, Clojure, Groovy, Scala, Fan... and they all play together incredibly
nicely. It's an amazing productivity boost to be able to use a dynamic
language (like Ruby or Groovy) to handle all the business logic and glue code,
while at the same time being able to take advantage of the speed of pure Java
when you need it.

~~~
jshen
This is so true, and I'm really curious which of the dynamic options will take
the lead on the jvm.

------
wildjim
Except that almost all these comments seem to assume a long-running / web
process.

Start-up times and memory requirements for the JVM are just horrendous; I
can't write a serious command-line tool in Java because of these constraints.
Even Scala has a compiler-tool which runs as a background task (fsc) because
of this.

~~~
jshen
let's hope mono catches on!

------
nir
"If we can leverage JRuby to grab 1-2% of the Java market, we'll _double_ the
size of the Ruby community" - that's pretty incredible.

IMHO it could be smart of the community to put some effort into getting JRuby
on Rails working smoothly on Google App Engine. GAE makes deployment and
scaling, traditionally RoR's weaker points (though much improved since
Passenger) almost a non-issue.

~~~
patio11
I would have agreed with you on "Rails sucks to deploy" two years ago, when I
started working with it, but the ecosystem is much, much better now. I don't
use Passenger in production (no real benefit to a single-app developer whose
app already works with Mongrel) so I won't comment on it, but Capistrano is
mature to the point where deployment to a VPS is very, very painless.

You should see how much fun the deploy procedure is at my day job (Big
Freaking Java Enterprise App) compared to "cap _1.4.2_ deploy".

As it happens I am looking at a stack of evaluations for the talk I gave
internally about GAE, which included redoing an internal app on it.
"Deployment is a non-issue" was not my experience. It is documented in the
traditional Rails manner: as comments on blog posts, most of them out of date.
It includes a lot of steps which are transparently bandaids over broken, like
"Freeze Rails then delete the ActiveRecord gem to save on files because GAE
has a hard limit on how many you can put in a WAR." It... bugger, meeting,
will complete this thought later.

~~~
patio11
Meeting over.

Other things not working on GAE, at least in my limited experience:

1) There is no way to run the console, period, which is a nuisance to my
typical development style.

2) There appears to be no good way to do testing, which is a showstopper for
many Rails developers. (I don't do TDD personally so not a big deal for me.)

3) Warble (wonderful software, don't get me wrong) has some performance
issues, at least on this computer. (30 seconds to change one line in one
file.) That wouldn't be a problem except...

4) ... I can't get GAE to operate locally with Rails, which means development
has to be done by edit, deploy, edit, deploy, edit, deploy, which combines all
the development speed of Big Freaking Java Enterprise Apps with the rich your-
IDE-will-spot-typos-for-you power of Ruby. (/sarcasm)

5) You can't use ActiveRecord on GAE, which sounds like a nuisance until you
realize how much of Rails magic depends on ActiveRecord being there.
Validations, for example. (This was a major GOTCHA! for us.) I hear this will
be mooted with Rails 3.0, which allows DataMapper (which will support Google's
data store) to be dropped in in place of AR, but it is one of the major issues
making me tell my bosses "The exploratory app was a big success, but the
platform is not ready for us to take it to production yet, even though you
have one production-ready app sitting in front of you."

~~~
nir
Once you're at the capistrano level, deployment is a different game.. I'm
talking about relatively small projects (I wouldn't deploy a big project on
GAE anyway, if only to avoid the lock-in to Google)

I totally agree on most of issues you raise (once GAE Rails would work
locally, console, testing etc could be resolved I suppose) - I would
definitely not build any size Rails project for GAE right now. But if Rails
community would put some work into that, I think it might be a great rapid
dev/deploy/scale solution.

------
itgoon
As someone who has spent a lot of time in those "lumbering" organizations, I
tend to agree.

While it isn't unreasonable to expect professionals to learn multiple
deployment scenarios, the sad truth is that it can be hard to arrange to have
such professionals.

Expecting someone who's career has revolved around
JBoss/WebLogic/Tomcat/whatever, to come to grips with the vagaries of mongrel
clusters is a recipe for failure. Not only does it mean learning something
new, something they may regard as a "toy", it is a solution which exists
outside of their domain, i.e., a threat.

That doesn't mean it can't be done, but it does mean being able to say "it's a
war file" is a huge and important lever.

------
raju
Not to take away from the discussion, but is anyone else attending eRubyCon
(<http://erubycon.com/>) that Charles mentions in this article. Would be nice
to meet and put faces on a few fellow HN'ers.

------
catch23
that's not so bad. clojure's past, present, and future is also java.

------
benreesman
scala is a better language than ruby anyways. if you rubyists want to promote
your language you had better get serious about staking out your turf on the
jvm, which is (i'm sorry to say) the only non-microsoft place where the
enterprise can find serious concurrency and gc.

the various full stack rubies are cute, but if i don't have grown up
concurrency then i'm not interested.

~~~
donw
Sounds like someone needs a hug.

~~~
benreesman
weak.

~~~
benreesman
you're entitled to the downvotes, but I had hoped that they might be
accompanied by a reply or two.

without that i'm left wondering if the disagreement/disapproval comes from
ruby advocates with no facts to back their arguments or people who think that
underendowed "office space" jokes are a valid retort for ruby fans with no
facts to back their arguements.

I guesss maybe I do have a case of the Mondays, but you have undergraduate
class project garbage collection and worse threads. Go charge $300 dollars a
seat for your motivational ruby seminar or something. Scrum's at 11am.

~~~
steveklabnik
If you were looking for replies, you might want to consider re-phrasing the
way that you comment. A good way to engeder goodwill from others is to start
off by talking about them, and not about yourself. Compare "If you were
looking for replies," (starting to talk about what you want) vs "Scala is a
better language than Ruby anyways." (which is an automatic trollish statement
that puts your intended audience on the defensive right from the beginning)

Now, first of all, it's entirely possible that the Ruby community as a whole
doesn't care about getting into the enterprise. I don't pretend to speak for
the whole community, and obviously (via the article), some do. Competing on
the JVM may not be the best way to promote the language as a whole. As you've
said, the space is getting crowded, and if Ruby bets its cards on being the
dynamic language of choice for the JVM, and then misses its target, how would
that look? I won't deny that JRuby is an awesome thing, as I personally would
like to see Ruby used (almost) everywhere. However, it's not as if, say, PHP
gets maligned because it's not 'enterprisy' enough. It does for totally
different reasons, and well-deserved ones at that. But the language is doing
quite well without being able to be run on the JVM.

As far as concurrency and garbage collection go, I think it's hardly fair to
judge all of Ruby on 1.8.7. YARV holds quite a bit of promise, and just goes
to show how with just a little bit of care, Ruby can be made to be on par with
every other language out there. See the link below for the comparison between
1.9 and 1.8. Now, in a pragmatic sense, this doesn't affect things _right
now_, but they do change the near future quite a bit. So yes, Ruby's
concurrency and gc may not be the best, but it's not as if there's no
improvement or work being done.

[http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=yarv&lang2=ruby&box=1)

