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

81–90 of 119 posts

Re: JRuby 9000 released

#81

Post by jrochkind1 »

dragonwriter wrote: post #51
Freaky wrote: 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.

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.

Re: JRuby 9000 released

#82

Post by jrochkind1 »

chrisseaton wrote: post #43
WaxProlix wrote: post #35

Earlier quoted context omitted.

Like what? They both benefit from the lack of GIL (Jython maybe moreso) as well as the portability and other benefits of JVM as a platform.

Jython doesn't use advanced functionality like invokedynamic.

It's unclear how much benefit invokedynamic actually provides at present, I recall seeing benchmarks not showing much.

I think the big JRuby advantage is actually that by and large code written for MRI Just Works on JRuby. The exceptions are relatively few, and usually easily worked around, or if not quickly bug fixed. Despite this thread, I haven't had significant troubles with ActiveRecord-ODBC, although in Rails 4.2 have occasionally run into relatively minor worked-around-able issues.

My impression is that code written for standard Python tends to have a lot more trouble running on Jython -- not from any fault of Jython, but because 'standard' Python code tends to be more likely to use native C than typical ruby.

Re: JRuby 9000 released

#83

Post by tinco »

eropple wrote: post #49
Freaky wrote: 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.

"Commonest" is a big claim. I'm not a JRuby user, but I sling a whole bunch of Ruby and I've never, not once, used the global regexp stuff--indeed, I didn't know it existed before just now. I can see wanting it fixed, but it's a pretty odd hill to die on.

I've been writing Ruby for 7 years now, and I've known about the regex svars for about as long. Never used them once. They're obviously bad style.

Re: JRuby 9000 released

#84

Post by ch4s3 »

headius wrote: post #65
ch4s3 wrote: post #44

Earlier quoted context omitted.

Yep, I've put up money for it myself, and regularly be on twitter for other folks to do the same. I wish a big company that uses jRuby would step up and support the tools they use :/

Agreed.

Know anyone? ;)

Re: JRuby 9000 released

#85

Post by nirvdrum »

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.

If you're open to alternatives, I highly recommend using Sequel. It integrates fairly well with Rails, optimizes extremely well on JRuby, has a consistent update schedule, and has a real API for developing plugins against. I realize it's not part of the standard Rails stack, but it actually makes upgrading Rails easier because you're not constantly chasing a non-standard API that changes release to release (even on MRI, ActiveRecord "plugins" break with almost every release).

Disclaimer: I now work on JRuby full time. But prior to this I ran Mogotest and switched to Sequel successfully on that project.

Re: JRuby 9000 released

#86

Post by nirvdrum »

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…

Do you have anything you can point at regarding String performance? Everything I've seen shows JRuby being faster than MRI. But I'm looking to see if we can make it even faster than it currently is. Any pathological cases would be incredibly helpful.

Re: JRuby 9000 released

#87

Post by headius »

jrochkind1 wrote: post #80
headius wrote: post #60

Earlier quoted context omitted.

This is not a hard one to fix but it didn't make the final release and had never been reported before, despite being largely the same for 9 years. It will be fixed as soon as we can get to it. I will echo what others have said, though...closures capture and share a lot of other state. $~ and the related vars like $1 are supposed to be "special" but there's other state you're going to stomp on all Ruby impls. It's bet…

Huh, if the local various was only scoped to the closure block, and not above it, I would never expect it to be shared. I would think "avoid using closure state" means exactly that, use only local variables scoped no higher than the closure block itself. (It's true this can sometimes be difficult to ensure in ruby; block local variables can help). Do I understand things right, or am I wrong here? I guess the question…

You're largely right. The problem is that $~ (and related vars) and $_ are scoped to the nearest method body. If they were scoped to the closure itself, there'd be no problem.

Re: JRuby 9000 released

#88

Post by headius »

jrochkind1 wrote: post #82
chrisseaton wrote: post #43

Earlier quoted context omitted.

Jython doesn't use advanced functionality like invokedynamic.

It's unclear how much benefit invokedynamic actually provides at present, I recall seeing benchmarks not showing much. I think the big JRuby advantage is actually that by and large code written for MRI Just Works on JRuby. The exceptions are relatively few, and usually easily worked around, or if not quickly bug fixed. Despite this thread, I haven't had significant troubles with ActiveRecord-ODBC, although in Rails 4…

Invokedynamic's benefits have been a bit of a mixed bag, but id does make the JVM see through dynamic call sites and optimize them like it does statically-typed call sites. That generally improves performance for JRuby, but there are cases where simply inlining the code together doesn't lead to a measurable increase.

Re: JRuby 9000 released

#89

Post by Twirrim »

rurounijones wrote: post #53
ch4s3 wrote: post #45

Earlier quoted context omitted.

No, its just a drag to TDD with.

I and others have had success with MRI on dev and JVM in prod to get around this. Maybe not for everyone but as long as you know what you are doing it is viable I think.

provided you final build, tests and do some sanity checking under JRuby, it should surely meet most needs?

Re: JRuby 9000 released

#90

Post by Twirrim »

pesnk wrote: post #8
gary4gar wrote: post #5

is it faster than MRI?

Course it is. JRuby has been faster then MRI for a long time. That does not mean I use it for production.

> That does not mean I use it for production.

Any particular reason why? (I'm just curious, I do absolutely nothing with ruby)

Post reply on HN