Sun Backs Ruby by Hiring Main JRuby Developers

pate writes "Sun has thrown some corporate weight behind Ruby, Rails, and dynamic languages by hiring the two main JRuby developers, Charles Nutter and Thomas Enebo. Charles posted about jruby stepping into Sun on his blog, and Thomas posted his take too. Tim Bray, who started the ball rolling posted about the JRuby Love."

Comments

Great News

[RAMMS EIN]

This is great news for several reasons.

First, and most importantly, because Sun is now throwing its weight behind Ruby, which is a wonderful language. It does have its quirks (some weird syntax and the schizophrenia between procs and blocks), but it's still one of the better languages out there. Easy to write and understand, powerful, and succinct.

Secondly, because Sun is supporting JRuby, which is an alternate implementation of the language. This will put pressure on the language designers to spell out the language in a clear specification, rather than referring to some implementation for knowledge of how things work. One of the benefits of this is that it will cause features to be thought and debated about more, which I believe results in cleaner, nicer languages.

Thirdly, because the JRuby folks seem to have the plan to develop a compiler. This could lead to Ruby's run-time performance increasing enormously, widening the scope of the language to tasks that current Ruby implementations are simply too slow for (you can extend Ruby programs in C and JRuby programs in Java, but it would be preferable if one didn't need to).

Fourthly, because there is just a slight chance that Sun will decide to make the JVM more flexible and amenable to languages other than Java. Right now, the operations that the JVM supports are very much tied to the features of Java. Implementing some more flexible primitives would benefit not only JRuby, but also about any other language that targets the JVM, and make the Java platform more competitive with .NET.

Re:Great News

[Per Wigren]

The language itself isn't slow, the current interpreter is.

The solution is YARV (Yet Another Ruby VM) which will be the official Ruby VM in v2.0. Ruby 2.0 (thanks to YARV) will have JIT and a superfast optimizer. You can get a (very buggy) pre-beta version from SVN right now. Benchmarks show that it will be about as fast as Java and .NET in most situations. Slower in some situations, faster in some.

Re:Great News

[arivanov]

First, let me ensure I got my trenches dug to the correct depth to duck for cover.

The answer is: Because it is not French.

The sole and only reason for not using smalltalk especially in the US is the not-invented-here mentality. I have yet to see a telecoms (dunno about other parts of the industry) smalltalk project whose roots are not from continental Europe. For example the Infovista carrier stuff which uses a smalltalk core was aquiried from Quallaby which surprise, surprise started its life as a french company. There are other examples as well, but I have yet to encounter a telecoms project which uses Smalltalk as its primary language and was started in the US (or UK).

Similarly, if you dig into any pre-2004 Ruby project you end up encountering some Samurai smiling at you with that characteristic smile that makes you feel like sushi.

Anyway, now it is time to duck in the freshly dug trench and wait until the flames have died out.

Re:Great News

[masklinn]

Mmm reasons for not using Smalltalk:

• It's syntax is fairly alien. Most people don't like alien syntax. Ruby's syntax is much more in line with "traditional" languages such as Java
• Ruby also has quite a lot of Perlish roots, which make it a quite "practical" language.
• Smalltalk is a fairly unique language in the sense that it's image-based: your code always lives in your image, you never need to get out of the environment, the feeling is different
• Smalltalk is fairly old, since it never took of most people never heard of it.
• Last, but probably not the least, Smalltalk was quite "closed" as an architecture, for a long time the only useable implementations were commercial, which was not a good thing since there were no heavyweight backers of the language (C# has the former issue of a primarily commercial -- even if free via C# compilers and Visual C# Express -- implelementation, but it has all the weight of MS behind it)

But yeah, Ruby is much closer to Smalltalk than Lisp indeed, Ruby's main "ancestors" are Smalltalk and Perl with some bits of Lisp & others thrown in.

The way I see things...

[Anonymous Coward]

Ruby (which is slow as molasses) could potentially see a higher speed gain from running on the JVM than Python has (not) seen from being ported to run on the CLR. However, I don't understand the technical advantage of these dynamic languages being ported to runtimes designed to host static languages.

Lua is interesting, it runs on it's own register based VM and LuaJIT does exactly what you think. Lua is only a small language and generally faster than C-ruby and C-python. I don't see anybody rushing to port this to run on the JVM/CLR, is this because the performance and memory use would absolutely suck?

GPL?

[giafly]

Currently JRuby is licensed under the GPL.
Given Sun's past criticism, I think it's fair to ask whether they have committed to using the GPL for future JRuby releases.

Re:Bad News

[RAMMS EIN]

I very much doubt that. It's languages like Perl, PHP, Ruby, and Python that have the odd features that cause massive problems when the language grows out of its initial niche and starts being applied to large, Real World problems. Many of these languages have little hacks that seemed advantageous when originally conceived, but later turned against them. Java has comparatively few of these issues (no list context vs. scalar context, scopes that don't nest, unpredictable syntax, etc.) - its main problem is that it's extremely verbose and repetitive.