McGovern Likes JRuby...

[Per Jacobsson]

You seem to imply that folks will either use Ruby or Java, but not
both. In JRuby, it's safe to say they'll complement each other. I
don't expect that in five years all app servers will be written in
Ruby from the ground up. But I do expect they'll use Ruby in
surprising and significant ways to tie together other code and
components written in Java.

A good example is actually what BEA are doing with Jython in their WLST
(Weblogic Scripting Tool, or whatever it means). They allow you to write
the configuration scripts for your application servers in Jython, that
then hook into the Java side thru JMX. It works pretty well and is nice
and flexible. JRuby could obviously be used for similar things.

Hi, new guy here. Enjoying the discussions!
/ Per

 

[M. Edward (Ed) Borasky]

Talk about trolling...

Yeah ... it's become a tradition for me every Saturday to try to be
provocative.

JRuby could only become the "one true way" if the community decided to
move that direction. I have no desire to make that happen; I just want
to make JRuby as good as possible. If the end result is what ALL
Rubyists actually want out of Ruby, great. I don't expect that will
happen. However I know it will be the right answer for a growing
number of Rubyists, and certainly the right answer for Ruby in a Java
world.

I think the best answer is for Rubyists to avoid thinking about JRuby
in terms of Java. JRuby is Ruby, with a different VM underneath. If
you could have Ruby on VM X, where X had full native threading,
advanced garbage collection and memory management, fast synchronous
and asynchronous IO, JITing to native code, runtime optimization, and
built-in support for dynlangs, wouldn't you want that?

That's the JVM.

That's the JVM on x86 (32?) under Windows, Linux and SPARC/Solaris. How
about PowerPC Macs? Intel Macs? AMD64? Alpha/Tru64?

Again, *I* don't support dropping other implementations of Ruby. If
nothing else, Microsoft will make at least one release of at least one
Ruby implementation. And I'm sure Matz and Koichi will continue
leading the community path.

The community path doesn't have to exclude paid developers from
Microsoft or Sun. I am as much a part of the community as you are.

I'm glad to hear that. As I noted in another post, however, many more
people in the corporate world get paid to work *with* open source
software than get paid to work *on* open source software. For every
lucky Charles Oliver Nutter or John Lam, there are hundreds of people
like me who can only contribute in off hours and to things not related
to our employment.

There's energy, but not numbers. Rubinius is cool, no doubt about
it...I just hope more folks step up to the plate to help contribute
time and effort into it.

Well ... there are some corporations who haven't taken a major stake in
Ruby like Sun and Microsoft have.

Cardinal's only problem is that it suffers from Parrot.

All I know about Parrot is what I read in the O'Reilly book on Perl 6
and Parrot. I don't know what's wrong with Parrot, but I can't imagine
that it's anywhere near as good as the JVM.

And perhaps once JRuby runs Rails perfectly, or exceeds YARV
performance, or this or that, we'll be moved on to other projects. But
there's a lot of potential in sticking with JRuby for the long haul. I
realize that, and Sun realizes that. You can FUD all you like, but
believe me: Sun is serious about this stuff.

Sun is serious about a lot of things. Intel was serious about a lot of
things until AMD started eating their breakfast (nobody will *ever* eat
Intel's lunch or dinner.) Then they said, "OK ... lay off a bunch of
managers ... focus on our core business ... sell off unprofitable
businesses."

I agree there's a lot of potential in sticking with jRuby for Sun. That
potential needs to be converted to profit, and that can only be done by
being competitive in the marketplace -- by satisficing rather than
optimizing.

Ola already mentioned that JRuby is as open-source and
community-driven as anything. There's a growing community of
contributors, Ola is part of the core team, and we're going to add
more non-Sun committers soon. Claiming that JRuby is somehow less open
or less communal than C Ruby is pretty silly.

Well ... my choice of the Matz/Koichi line has more to do with my lack
of knowledge of the JVM and CLR than it does with the nature of how they
are funded. But judging by the howls in the Linux community that went up
over the Microsoft/Novell deal, the persistent whining around Sun's slow
pace at opening up Java technology, I think the Matz / Koichi path is
more likely to be more peaceful, in addition to being more interesting
in the computer science sense.

 

[M. Edward (Ed) Borasky]

It's funny you should say that just today:
http://www.eweek.com/article2/0,1759,2055994,00.asp?kc=EWRSS03129TX1K0000616

My browser (SeaMonkey) goes to the eWeek home page on that link. What's
the search term?

 

[Ola Bini]

My browser (SeaMonkey) goes to the eWeek home page on that link. What's
the search term?

That URL seems to have been closed down, for some reason. It was a post
announcing the open sourcing of the JVM with quotes from Rich Green that
made it clear the JVM is open sourced under GPL.

--
Ola Bini (http://ola-bini.blogspot.com)
JvYAML, RbYAML, JRuby and Jatha contributor
System Developer, Karolinska Institutet (http://www.ki.se)
OLogix Consulting (http://www.ologix.com)

"Yields falsehood when quined" yields falsehood when quined.

 

[M. Edward (Ed) Borasky]

That URL seems to have been closed down, for some reason. It was a
post announcing the open sourcing of the JVM with quotes from Rich
Green that made it clear the JVM is open sourced under GPL.

Ah ... today's the day, eh? Well, I'm sure it will show up elsewhere.
Meanwhile, why the GPL, as opposed to the same license OpenSolaris uses?
Is there some GPL technology connected with the JVM?

 

[Charles Oliver Nutter]

That's the JVM on x86 (32?) under Windows, Linux and SPARC/Solaris. How
about PowerPC Macs? Intel Macs? AMD64? Alpha/Tru64?

I develop on OS X on Intel and in Linux on AMD64. There are JVMs for all
the platforms you list, most based on Sun's own with additional
platform-specific enhancements. There are free JVMs for just about every
platform available these days, and a whole raft of commercial VMs for
the remainder. The JVM is everywhere, which means that JRuby could be in
every one of those places with a solid VM under it.

I'm glad to hear that. As I noted in another post, however, many more
people in the corporate world get paid to work *with* open source
software than get paid to work *on* open source software. For every
lucky Charles Oliver Nutter or John Lam, there are hundreds of people
like me who can only contribute in off hours and to things not related
to our employment.

And we will always appreciate you taking some of your precious off-hours
time to help JRuby Of course at Sun we're all working on open-source
software...and there may be more companies turning this direction in the
future. You know how it is...if you can't change your job, change your job.

Well ... there are some corporations who haven't taken a major stake in
Ruby like Sun and Microsoft have.

But those two moves have certainly made others in the industry take
notice. I hope more corps will make an investment soon.

I agree there's a lot of potential in sticking with jRuby for Sun. That
potential needs to be converted to profit, and that can only be done by
being competitive in the marketplace -- by satisficing rather than
optimizing.

This is actually Tom's point, but all projects have to satisfice or they
never release. Ruby 2.0 so far is not satisficing, and is not going to
be released anytime soon. Parrot is not satisficing, and it's unclear
whether it will ever be done.

The other half of this is that JRuby isn't just going to be driven by
the two Sun employees that work on it; it will be driven by its
community, hopefully by Ruby converts that want another VM option, and
by more big players in the future. If both Tom and I were hit by a bus,
JRuby would go on.

Well ... my choice of the Matz/Koichi line has more to do with my lack
of knowledge of the JVM and CLR than it does with the nature of how they
are funded. But judging by the howls in the Linux community that went up
over the Microsoft/Novell deal, the persistent whining around Sun's slow
pace at opening up Java technology, I think the Matz / Koichi path is
more likely to be more peaceful, in addition to being more interesting
in the computer science sense.

Perhaps; but it's also affected by the limitations of the current
interpreter. Ruby 1.9/2.0 has so far been hindered by the desire to keep
C extensions working, which prevents improvements to the memory model,
GC, core API, method dispatch logic...etc. YARV mainly just swaps out
the AST-walking interpreter--providing a big interpretation boost--but
not much else will change.

Those other pieces will get attention in time, of course, but it's not
clear now on what timeline we'll see them.