Live data from Hacker News

JRuby 9000 released

blog.jruby.org

91–100 of 119 posts

Re: JRuby 9000 released

#91
post #19
post #5

is it faster than MRI?

The real advantage comes from the fact that JRuby isn't enslaved to a GIL like MRI, so you get JVM threads out of the box. Even with the JIT, JRuby (at least 1.7) isn't appreciably faster than MRI when running a single-threaded app: http://www.isrubyfastyet.com/

These benchmarks are very small and do not run long enough for the JIT to really kick in. Many of them are also so synthetic as to be meaningless.

Re: JRuby 9000 released

#92
post #78

Earlier quoted context omitted.

Ah, I didn't get that from your original post. So JRuby 9000 shipped with a known concurrency bug that, from the face of it, seems likely to be a problem in actual use. I agree that seems a bit worrying.

You have to ship some time. Noisy bugs get fixed...and patches are always accepted :-)

Of course is can be completely reasonable to ship with a known bug, which is why my initial reaction to the OP was: why are you bringing this up here?

However, not all bugs are made equal and this one seems relatively likely to actually cause problems for users. Wouldn't someone running some service and handling say 10 requests/second, while using the regex global variables, run into this bug on a daily basis?

So I guess I'm just interested in how such a decision is made: what bugs get shipped and which block a release?

If this bug would reasonably cause problems in such a situation and if the policy of JRuby is to ship anyway, that seems to be a relevant piece of information to consider for someone using JRuby in production and considering whether to upgrade.

Perhaps one should always check the list of open bugs for the version of a compiler/interpreter one intends to start using, but I've never done so, haven't been bitten by a bug yet (AFAIK) and yet this one seems one that could be a problem. The main problem is of course that this may just be 'the curse of knowledge' in play.

So I guess I was being a bit dismissive towards OP, then I was sympathetic and now I'm mostly thinking about how I should handle this as someone using JRuby in production. Perhaps I should just ignore it. Perhaps I should investigate the set of concurrency tests and contribute a few. Perhaps I should be conservative and only use 'proven' JRuby versions. Perhaps I should learn to stop worrying and love the bomb :)

Re: JRuby 9000 released

#93
I've actually found JRuby to be very handy when it comes to packaging. Using warbler I can generate a jar file and then using the javapackager I can create self contained packages for all the major platforms/package managers: windows (.exe/.msi), linux (.rpm, .deb), osx (.dmg). Way more painless than packaging a ruby runtime. I've tried traveling ruby, but have not had the same seamless experience. Especially when it comes to multiple platforms. However, packaging with java, jruby and my application usually turn out to be quite large. Around 80Mb for a CLI and the startup time for short running programs like CLIs using JRuby can be quite long.

Re: JRuby 9000 released

#94
So why does JRuby never got as much traction as other jvm langs like clojure, scala, groovy? I have heard good things about the ruby syntax, top that you get unparalleled powers of jvm like gc, cross platform, libs and much more!

Re: JRuby 9000 released

#95
post #94

So why does JRuby never got as much traction as other jvm langs like clojure, scala, groovy? I have heard good things about the ruby syntax, top that you get unparalleled powers of jvm like gc, cross platform, libs and much more!

For the same reason that alternative implementations of Python never got the kind of traction they deserve, because 90% of the gems, libraries and everything are specifically tailored to MRI and it's always harder to play catch up.

Also, the strong anti-Java culture in the Ruby community probably didn't help (even though JRuby has nothing to do with Java, or very little).

Re: JRuby 9000 released

#96
We're using JRuby in some core projects and it's great. From my experience (moved 2 high load projects to Jruby) transition to JRuby from Ruby is not just changing Ruby version. But often you spend around 1-2 weeks to move medium size project on it, change some gems and configure Java options to not have out of memory errors. So it works fine, I'd not say that it works much faster than latest Ruby. But I think that main reasons why you should switch are multithreading and Java libs. We switched because of we was need to use latest Java libs for Kafka. But the main disadvantage is that sometimes when you need to deal with Java objects you need to think about object data type casting (from Ruby object to Java and vice versa). And this is extra actions, extra memory usage.

I'm very happy to see JRuby 9000 and hope we'll upgrade soon.

Re: JRuby 9000 released

#97
post #46

Earlier quoted context omitted.

The same bug still exists in JRuby 9000, and was in fact the first thing I ran into when trying it. Considering threading is the main selling point, one of the commonest patterns of regexp use being completely and dangerously broken with them would have seemed like something of a showstopper.

> one of the commonest patterns of regexp use Is it really? Even fairly early in the Ruby 1.8.x era, most recommendations I saw were that the magic regexp globals (and many other magic globals) were a perlism that should generally be avoided.

I don't think it's that common a pattern. All those perlisms make code unreadable anyway. I much prefer things like match with named captures, which generally make everything more obvious.

Re: JRuby 9000 released

#98
post #78

Earlier quoted context omitted.

You have to ship some time. Noisy bugs get fixed...and patches are always accepted :-)

Of course is can be completely reasonable to ship with a known bug, which is why my initial reaction to the OP was: why are you bringing this up here? However, not all bugs are made equal and this one seems relatively likely to actually cause problems for users. Wouldn't someone running some service and handling say 10 requests/second, while using the regex global variables, run into this bug on a daily basis? So I g…

Of perhaps you should simply shy away from global perlisms in a Ruby app, which are really bad practice anyway.

Re: JRuby 9000 released

#99

Earlier quoted context omitted.

> one of the commonest patterns of regexp use Is it really? Even fairly early in the Ruby 1.8.x era, most recommendations I saw were that the magic regexp globals (and many other magic globals) were a perlism that should generally be avoided.

Huh, I use `$1` all the time, and see it all the time. Probably because the alternative with an explicit match object ends up being relatively a lot more code and a lot harder to read, really. If avoiding `$1` has been often recommended for a while... I think it's a recommendation more often ignored than followed.

I've never seen $1 used in production code.

Re: JRuby 9000 released

#100
post #68
post #9

JRuby is a great idea. It has one pitfall which consistently stops me from using it though : poor support with newer releases of Rails, usually due to the Active Record stack not working well with the AR JDBC adapter. I know some work was being done on a JRuby version of the standard pg gem (without the need for JDBC) which would be fantastic if it was completed and working.

This is really an unfortunte side effect of every Rails AR adapter being a one-off piece of code. In JRuby, there's not much code different between the databases, but in Rails they're all completely different. That means we basically have to emulate N different codebases just to be compatible. If they settled on a common database layer, our job would be done. Write your congressman.

Coyld an alternative be to simply add a single jdbc adapter to rails instead of pretending to have a lot of different interfaces in parallel?
Post reply on HN