Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JRuby 9000 released

blog.jruby.org

Post reply on HN
Print view View original

21–30 of 119 posts

Re: JRuby 9000 released

#21

Post by amalag »

astrodust wrote: post #15
aurochs wrote: 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.

Define "newer" and define "poor"? The JRuby team has done a fantastic job of keeping things working. Do you have any specific problems other than vague grumblings? Anyone married to the MRI ecosystem because of dependencies on modules with no JVM equivalent may have problems, but new projects usually have no such issues.

I don't want to complain because it is a free product. But there is no doubt a big lag with activerecord. Rails 4.2 is still not supported: https://github.com/jruby/activerecord-jdbc-adapter/issues/59...

Re: JRuby 9000 released

#22

Post by FooBarWidget »

astrodust wrote: post #18
FooBarWidget wrote: post #16

Earlier quoted context omitted.

That depends on what you mean by faster. For CPU-bound work, JRuby is almost always faster. The JVM is very good at optimizing. However, the best performance doesn't kick in until the JVM is sufficiently warmed up, which means JRuby shines mostly for long-running tasks. Warming up can take a few minutes, although some people tell me that I should warm up for half an hour (!). On the flip side, JRuby starts much more…

In practice I've found the start-up times aren't all that different. The drag is more pronounced on older hardware, though. A current i5 or i7 system with an SSD is usually roughly the same.

That is very contrary to my experience. A Rake task in a Rails project almost always takes somewhere like 15-20 seconds just to start up (on MRI it's around 2-5). Just today, I tried to run the Middleman static site generator. Where on MRI, Middleman starts building after around 3 seconds, on JRuby it starts building after around 10 seconds. And I'm on a 2012 Macbook Air.

Re: JRuby 9000 released

#23

Post by ericb »

gary4gar wrote: post #5

is it faster than MRI?

At least with the previous JRuby, for us the answer is "usually no." If you do any large string ops (hello JSON), or parsing, or use any ruby gems which use exception handling for flow control (which is cheap in MRI, but like 9ms per exception in JRuby) in a loop then you will be slower. Also, SSL connection negotiation is exceedingly slow in JRuby 1.7x (like 100ms) and this made our microservices tough. Using HTTP Client with keepalives helped with this.

In a hello world, you might come out ahead in 1.7.x. Maybe 9000 is better?

Re: JRuby 9000 released

#24

Post by fny »

aurochs wrote: 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.

As far as I'm aware, the port of pg 0.17.1 is alive and well: https://github.com/headius/jruby-pg

Re: JRuby 9000 released

#26

Post by mrkrwtsn »

joegyoung wrote: post #7

If I committed to using jRuby instead of regular ruby, I would have that nagging fear that Oracle would go after all the other companies that build their product using Java APIs.

How would that help them? It doesn't seem like they have any incentive to prevent more people from using the JVM. In fact, I would imagine they want more people to use it, and multiple languages compiling to it makes it more popular.

Re: JRuby 9000 released

#27

Post by Freaky »

Concurrent threads using magic regexp vars like $1 stomp all over each other, quite nasty: https://github.com/jruby/jruby/issues/3031

Stumbling over a serious race condition in the first 5 minutes of trying it with real code makes me a bit wary. All the performance in the world isn't much good if it's randomly wrong :/

Re: JRuby 9000 released

#28

Post by cheald »

ericb wrote: post #23
gary4gar wrote: post #5

is it faster than MRI?

At least with the previous JRuby, for us the answer is "usually no." If you do any large string ops (hello JSON), or parsing, or use any ruby gems which use exception handling for flow control (which is cheap in MRI, but like 9ms per exception in JRuby) in a loop then you will be slower. Also, SSL connection negotiation is exceedingly slow in JRuby 1.7x (like 100ms) and this made our microservices tough. Using HTTP C…

I wrote Manticore (https://github.com/cheald/manticore) because of my dissatisfaction with Ruby HTTP clients under JRuby; it uses the Apache HTTPComponents (completely sidestepping Ruby's stdlib http/networking stuff) and is extremely fast. It might be worth looking into for you.

Re: JRuby 9000 released

#29

Post by juliangregorian »

amalag wrote: post #21
astrodust wrote: post #15

Earlier quoted context omitted.

Define "newer" and define "poor"? The JRuby team has done a fantastic job of keeping things working. Do you have any specific problems other than vague grumblings? Anyone married to the MRI ecosystem because of dependencies on modules with no JVM equivalent may have problems, but new projects usually have no such issues.

I don't want to complain because it is a free product. But there is no doubt a big lag with activerecord. Rails 4.2 is still not supported: https://github.com/jruby/activerecord-jdbc-adapter/issues/59...

Currently, there's $1700 in store for whoever does support it: https://www.bountysource.com/issues/5831191-tasks-to-finish-...
Post reply on HN