Slashdot Log In
Sun Backs Ruby by Hiring Main JRuby Developers
Posted by
ScuttleMonkey
on Tue Sep 12, 2006 04:31 AM
from the feel-the-love dept.
from the feel-the-love dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Great News (Score:5, Interesting)
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
Re: (Score:2)
BTW, any project with a lead developer named "Charles Nutter" deserves respect!!
Re: (Score:3, Funny)
A fast Ruby with a compiler is called Common Lisp.
Re: (Score:2)
I should have added ;-)
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
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 c
Re: (Score:3, Insightful)
My opinion on why we don't use Smalltalk? When it came out, the world wasn't ready for it. We were still getting our heads around object oriented programming in general. The fact that it didn't use C syntax didn't help either. Smalltalk was just too much for most programmers to learn. Nowdays, since it is decades old, it doesn't have the same sparkle of a newer language, like Ruby.
Re: (Score:3, Interesting)
Mmm reasons for not using Smalltalk:
Re:Great News (Score:5, Interesting)
The solution is YARV [atdot.net] (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
Parent
Re:Great News (Score:4, Insightful)
Yes, but the JVM is a moving target. By the time all those bugs have been ironed out, JRuby will have improved their execution speeds too. Lets not declare the winner until we have the finished products to compare, otherwise we are just playing the old Microsoft game of "lets compare the features of our future products with the features of our competition today".
Parent
Re: (Score:2)
I don't know why you would think that. Ruby is very young yet, and not a lot of effort has gone into making it run fast. Even if the JVM introduces a bit of a slow down compared to native executables (which is a topic of heated debate), it's entirely possible that a JVM implementation of it will outperform the current, slow C implementation.
Re: (Score:2)
Ruby is older than Java.
That one's right though, the current implementation of Ruby is pretty much the slowest way you could ever implement it. All the backend should be reimplemented for Ruby 2.0 (including a true VM) with YARV.
Re: (Score:2)
Re: (Score:2)
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.
I think this mainly means adjusting the assembler of Ruby to output code that can be unders
Re: (Score:2)
Of course, and I didn't say that Ruby _can't_ be made to compile to JVM bytecode, I just said that the JVM bytecode is very much tied to Java. If you look at the sp
Re: (Score:2)
I also seem to recall that the next version of Java will have some enhancements for dynamic languages (though it came out of Sun's effort to port Visual Basic to Java)
Re: (Score:3, Informative)
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.
JSR 223 [jcp.org]
Re: (Score:2)
That goes to show how important it is to design your language to be flexible from the start. Java is the kind of language you _have_ to modify to get some desireable features. See, for example, the overhaul of the type system that was necessary to get co
Re: (Score:2)
Re: (Score:3, Informative)
AFAIK, The 6th major revision of the Java platform, codename Mustang, already provides a well d
Re:Great News (Score:4, Insightful)
Two seconds of Googling could have told you that the JVM has supported more languages than
I don't think they will ever be able to top the
You do know that Java is MUCH bigger than
More probable: Sun is going to add Ruby on rails to their JSP system, which is probably the only way they kan add anything to anything.
You really have no idea what you are talking about. Java developers could use Ruby to do fast and easy unit tests for instance. The scripting sessions at the last JavaOne showed lots of other interesting uses. Also it wouldn't surprise me if one possible long time plan wouldn't be to make the JVM the fastest, most stable and therefore the most attractive platform to run all Ruby programs.
Parent
Re:Great News (Score:5, Insightful)
I may be overreaching here, but I think that part of his point was that Sun never ever officially endorsed any language but Java on the Java platform. Only now that MS has started championing a pretty much official IronPython effort has Sun discovered dynamic languages, and started working towards making the JVM more dynamic-languages friendly.
Which is a damn shame, because they had Jython years ago, which they could easily have supported at almost no cost, and they let the project die on it's own.
Parent
Re: (Score:3, Interesting)
Support for Dynamic languages (Score:5, Insightful)
Re:Support for Dynamic languages (Score:5, Insightful)
Parent
Re: (Score:3, Insightful)
Which is not the norm when you're talking abount Sun microsoystems.
Bye egghat.
Too young to remember Tcl/Tk at Sun (Score:2)
Back in 1994, Sun hired the core developer behind Tcl/Tk [www.tcl.tk], and asked him to form a team around the language / graphical toolkit. The toolkit was very widely used and quite promising (for the time), but it languished at Sun and eventually they dumped it.
Rich.
The way I see things... (Score:2, Interesting)
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 t
Re: (Score:2)
No, I suspect its because no one has even heard of it. Theres dozens of
me-too languages out there but until someone starts to use one a lot
and it takes off no one cares. Fact of life I'm afraid.
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
I think it's because they don't go for the same market. Lua's goal is to be a fast, simple embedded language, to enable easy scripting of your C/C++ applications for example (which is why Lua is used a lot in embedded and games devs).
Python and Ruby are full fledged, self-contained programming languages (even though you can embed them into C/C++ programs, or use C/C++ libs
Re: (Score:2)
The "technical advantage" is the more or less same as implementing them over the more common "C platform".
"It was a little less than a year ago that I first started investigating the Common Language Runtime (CLR). My plan was to do a little work and then write a short pithy article called, "Why
good thing, too (Score:3, Funny)
Good thing, because that Oswald guy was starting to get on my nerves.
GPL? (Score:5, Interesting)
Given Sun's past criticism [com.com], I think it's fair to ask whether they have committed to using the GPL for future JRuby releases.
Re: (Score:2)
Re: (Score:2, Insightful)
Re: (Score:2)
Of course they will, they can't change the licence to a less restrictive one. Also you could just have read . [bloglines.com]
Re: (Score:2)
Also you could just have read TFA, or the FAQs, or the blogs.
Jython -- they need a boost too (Score:3, Informative)
I just don't think they are taking
It would be interesting (Score:2)
I have seen JRuby code and the effort to use Java libraries from Ruby and it was plain scary, I would rather do pure Java. And support for rails is "miles before you and me can do some
after letting Jython languish (Score:5, Insightful)
I gots no love for Sun ... after all Jython been out for half a decade, and Sun has shown little to no interest in it ... just imagine how much better it would be if they had the foresight to support it and improve its performance
As far as I'm concenrned Sun is playing catch-up with Microsoft, and this is no more than a half assed response to MS releasing IronPython
Re: (Score:3, Informative)
Then Microsoft came along and released a Java that was a better Java, on top of a JVM that was a better JVM. On top of that, they actively supported language diversity, encouraged
Missing the point (Score:3, Insightful)
This is an insurance policy for Sun, and a way for them to provide a migration path and say "Oh, OK, you can run your Rails site on our Java platform while you build the next version using J2EE".
Re: (Score:2)
To be fair, Java does have some advantages over C and C++ for application development, and I think that Java has worked wonders in the corporate world.
``the best move would have been replacing Java with Ruby,''
Not necessarily. Java and Ruby have different strengths. For example, Java has static typing, which helps catch errors at compile time.
``Now, if and when some good Ruby software will be written by these folks which will rely on
Re: (Score:3, Informative)
So do many other languages. The main reason why Java worked wonders in the corporate world is marketting. Basically, Java is a victory of marketting over engineering.
Doesn't have near enough to be truely useful, and the explicit typing (lack of type inference) make it extreme
Re: (Score:2)
Re:Not exactly a good thing (Score:4, Informative)
I don't think portability is the real advantage. I even doubt if Java really is more portable. No, the real advantages are safety and garbage collection. C and C++ programs are rife with format strings, unchecked return values, unchecked casts, unsafe I/O primitives, and manual memory allocation. All of these are rich sources of bugs. Buffer overflows are in the top three of most common vulnerability types (probably first after injection vulnerabilities, which Java's SQL API protects against, too). Memory leaks are also common, e.g. Firefox suffers badly from them. Unchecked return values have been responsible for some major privilege elevation vulnerabilities in Linux. All of these can't happen in Java, or at least, Java greatly reduces the risks.
Parent
And don't forget about identifiers (Score:2)
Disclaimer: YMMV, and yes, I do know that you can use verbose identifiers in C/C++. That doesn't help much if nobody else does so.
Re: (Score:3, Insightful)
How about a bazillion prewritten, documented, tested, standardized, open source library modules, many of them supplied by Sun with the language, to do bigmath/network/file/database/sql/2D-3Dgraphic/GU
Tell you what, you roll anything trickier than "hello world" from scratch in C/C++, and I'll do the same in Java, and we'll see who has the choice of more predefined stuff to use, and who finishes faster with a program that runs more correctly.
Re: (Score:2)