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

41–50 of 119 posts

Re: JRuby 9000 released

#41

Post by dragonwriter »

mdavidn wrote: post #39
Scarbutt wrote: post #2

JRuby 9000 now uses native operations for much of IO and almost all of Process. This makes us the first POSIX-friendly JVM language. Did they achieved this via JNI?

This will prevent running JRuby 9000 in (today's) Google App Engine. The project has been drifting away from App Engine support for some time now. See #2304. https://github.com/jruby/jruby/issues/2304

> This will prevent running JRuby 9000 in (today's) Google App Engine.

It'll prevent running it on the current Google App Engine Java Runtime.

It won't, AFAICT, prevent running it in a Google App Engine Managed VM, which is an option on today's Google App Engine.

Re: JRuby 9000 released

#42

Post by chrisseaton »

mdavidn wrote: post #39
Scarbutt wrote: post #2

JRuby 9000 now uses native operations for much of IO and almost all of Process. This makes us the first POSIX-friendly JVM language. Did they achieved this via JNI?

This will prevent running JRuby 9000 in (today's) Google App Engine. The project has been drifting away from App Engine support for some time now. See #2304. https://github.com/jruby/jruby/issues/2304

There's a pure-Java fallback that has most of the same functionality. But if you wanted precise POSIX function calls you probably weren't running on App Engine anyway.

Re: JRuby 9000 released

#43

Post by chrisseaton »

WaxProlix wrote: post #35
brightball wrote: post #34

Earlier quoted context omitted.

jRuby is one of the biggest reasons I lean to Ruby over Python. Ruby gains a lot more from the JVM than Python (at least that's my understanding) does and that leads to much more momentum behind jRuby.

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.

Re: JRuby 9000 released

#44

Post by ch4s3 »

juliangregorian wrote: post #29
amalag wrote: post #21

Earlier quoted context omitted.

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-...

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 :/

Re: JRuby 9000 released

#45

Post by ch4s3 »

chaostheory wrote: post #36
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…

For things like Rails, that are going to be running all the time, does the JVM warm up time really matter?

No, its just a drag to TDD with.

Re: JRuby 9000 released

#46

Post by Freaky »

Confusion wrote: post #38
Freaky wrote: post #27

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 :/

Your comment has little to do with JRuby 9000, as the bug reported there was observed in JRuby 1.7.20. Yes, JRuby has bugs, like MRI, like any interpreter or compiler.

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.

Re: JRuby 9000 released

#47

Post by mdavidn »

dragonwriter wrote: post #41
mdavidn wrote: post #39

Earlier quoted context omitted.

This will prevent running JRuby 9000 in (today's) Google App Engine. The project has been drifting away from App Engine support for some time now. See #2304. https://github.com/jruby/jruby/issues/2304

> This will prevent running JRuby 9000 in (today's) Google App Engine. It'll prevent running it on the current Google App Engine Java Runtime. It won't, AFAICT, prevent running it in a Google App Engine Managed VM, which is an option on today's Google App Engine.

True, but many teams running Ruby in Managed VM will use opt to run YARV directly.

Re: JRuby 9000 released

#48

Post by rugmug5 »

Freaky wrote: post #27

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 :/

You really shouldn't be relying on globals anyway. Using $1 etc. is a serious code smell. It shouldn't by definition be threadsafe in any event. The only way that would work would be if you rely on the threads not actually running at the same time as an implementation detail of the MRI.

Re: JRuby 9000 released

#49

Post by eropple »

Freaky wrote: post #46
Confusion wrote: post #38

Earlier quoted context omitted.

Your comment has little to do with JRuby 9000, as the bug reported there was observed in JRuby 1.7.20. Yes, JRuby has bugs, like MRI, like any interpreter or compiler.

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.

Re: JRuby 9000 released

#50

Post by Confusion »

Freaky wrote: post #46
Confusion wrote: post #38

Earlier quoted context omitted.

Your comment has little to do with JRuby 9000, as the bug reported there was observed in JRuby 1.7.20. Yes, JRuby has bugs, like MRI, like any interpreter or compiler.

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.

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.
Post reply on HN