[tptacek]

C extensions are a very big reason why not; the pain of demand-starting JVMs is another minor reason.

[atambo]

I suppose it depends on what you're using ruby for. I use it for long running processes like rails apps so the jvm startup time really doesn't matter. And jruby has support for c extensions that use ffi.

[tptacek]

Nobody's saying not to use jruby. You asked a question, I gave one answer.

[Confusion]

The second is actually much less painful than people generally think. Jruby -e 'some code' only takes half a second on my machine, which is fast enough to not be a problem. The main slowness people experience has to do with loading gems, usually via rubygems. That is painfully slow, but does not have anything to do with JVM startup time.

[tptacek]

"jruby -e 1", cold start, just took 4 seconds for me. I use jruby interactively almost every day (it's extremely handy in penetration testing), and I'm pretty sure jruby is noticeably slower to start than MRI.

[Confusion]

It's definitely noticably slower, but 4 seconds per startup would make it unusable for me. However, since it's

  time jruby -e 1
  real	0m0.514s
  user	0m0.510s
  sys	0m0.040s

I find it acceptable (could it be the SSD in my laptop that makes such a large difference?). As http://jira.codehaus.org/browse/JRUBY-5181 shows, as soon as some gems come into the picture, actual startup times deteriorate rapidly.

[tptacek]

I'm not an SSD, but mine was also a cold start; are you sure yours wasn't already cached?

[Confusion]

I don't reboot that often, so it took me a while before I could try it, but my home desktop, also with SSD, gives

  user@twen:~/tmp$ time jruby -e '1'

  real	0m0.664s
  user	0m0.390s
  sys	0m0.110s

for a cold boot. Subsequent startups are 350-400ms. Stock JRuby 1.5.6