James Moore wrote:
So I have to ask - is JRuby a good thing for the Ruby community, as opposed
to the Java community? To me - admittedly, someone without a huge depth of
Ruby experience - it's not an obvious good idea.
Very few things are. If it gets support and ends up being Done Right - e.g. with good bidirectional integration. I'm thinking along the lines of Nemerle in .NET - one of the few non-MS .NET languages that a) actually adds new features instead of just rephrasing C#, and b) very nicely transparently both consuming the framework, and creating interoperating assemblies.
The best I can say is that I expect that it will be a good thing for someone. Since Java pays my bills, I wouldn't complain if JRuby brought benefits on that side of the fence. And then again, you get things like very decent support for newer W3C standards in Java libs soon, and being able to at least bite your teeth on them earlier -and- using a language you prefer is good for Rubyists too.
(PS: For those looking for a new language to play around with, and partial to ML-likes, or those that want to learn some functional programming from the lighter side of things, I can strongly recommend Nemerle. The optional indentation-based syntax I find easier to understand than Haskell's, the OO is more familiar than OCaml's take on that, AND you get the whole of .NET thrown in for good measure for instant "real-world" programming possibilities. No, I'm not a member of the project ;P)
The JVM is great for running client apps. On the server side it's less than
useful; it's just another layer on top of the operating system. Servers
have a well-understood interface, and putting something like .Net or the JVM
on them just gets in the way. Sure, it may be handy for some very strange
edge cases, but Ruby runs on all the environments that the mainstream cares
about - Unix variants. (OK, and you can run Ruby on Windows, but almost no
one will for production servers.)
You also obviously don't have great experience with with Java either. J2EE - mostly server-side computing is the single most successful application of the language bar none.
Desktop Java started out on the wrong foot and only barely caught on lately. The GUI toolkits are to blame for a lot of it. First came AWT, which was a pretty sub-par "smallest common denominator" GUI toolkit; to add insult to injury, AWT saw use with the earlier VMs which gave birth to the low speed myth - that one was quite justified then. Then came Swing. I have a strong love / hate relationship to Swing - I learned GUI coding on it, the Bean-structure API is still by far my favourite approach, and it has a great structure to code UIs in in source code as opposed to using a visual window editor. (I never quite got the hang of those, and am very willing to enter into long-winded flamewars with Visual Studio monkeys on how a good handcodable GUI is useful and how my preference is not a flaw.) However, Swing looked horribly for very long before Sun realised users want integration with their existing setup - AFAIK, only the upcoming Java 1.6 will actually use native APIs to draw controls to get a native look. 1.5s Swing looks passable until you heavens forbid change font resolution in Windows to Large fonts, when you get pixelated hell. And the fact subpixel font antialiasing isn't get annoying too.
Another problem with that is that Sun should have done one thing - added native binary emit features to javac. The part of the tutorial that says you have to call "java some.silly.class.Name" to run an app is just laughable, and just emitting a simple binary that would use JNI to start a VM in the process and start the program wouldn't hurt. This is where .NET frankly obliterates it, none of its idioms look out of place.
I'm guessing that for embedded devices Ruby isn't going to be a player, but
maybe I'm wrong and JRuby on something like a phone would be a huge plus.
I think someone ported Ruby to a Nokia tablet PC. For quick glue jobs and batches, it might be workable.
Adding a JVM layer means you can interface to Java libraries, sure, but how
important is that? Most of the time things provide interfaces in C, and
Ruby will accumulate ways of using those. Seems like a time-limited problem
here that would lock Ruby into a Java-centric world.
The Java-centric world is HUGE. You also get instant binary compatibility on all platforms and your only native dependency becomes the JVM, which is fairly well supported on all manners of stuff. Sure, Ruby works most of the time if you get all your dependency maintainers to provide Windows DLLs and your deployment boxes have gcc and devel libs to compile extensions.
Except not all native Ruby extensions have Windows ports available, and not all deployment boxes have GCC, and if deploying on a Debian box, odds are you won't have devel libs for everything installed, and then you're screwed. Most Java deployment is copying a JAR / WAR / EAR around.
Running on the JVM will mean that anything coded in C won't run, no?
Libraries that need screaming performance for particular carefully chosen
optimized bits aren't going to work with the JVM, and it strikes me as
bizarre to code in Java for performance.
As I said. Everything and its mum has a Java version these days, it's improbable you couldn't find an equivalent. Or ten. For screaming performance, there's always JNI to make a fast implementation - the Subversion bindings for Java do this for example.