Sun Backs Ruby by Hiring Main JRuby Developers 211
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."
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:2)
This was an IBM shop and IBM pushed Smalltalk as an upgrade path from COBOL. Then came this language called Java and it was OO, granted not as OO as smalltalk, but the development tools were and are free, or at least a lot cheaper... IBM dropped their smalltalk push
Re: (Score:2)
So, how does the not-invented-here syndrome explain why we are now using a language invented in Japan [wikipedia.org]?
I didn't even know smalltalk was french until I read this.
Re: (Score:3, Interesting)
Mmm reasons for not using Smalltalk:
Re: (Score:2)
I think you hit the nail on the head there, being a Perl hack (second class only) I like Ruby because I found it easy to tranlate over and I can do the crazy wierd Perl-like stuff that I cannot do in C# or Java (or have to jump through a lot of hoops to do).
All the while it is better in object orientation and they did clean a few things up as well.
Ruby is becoming my new Perl. I predict more Perl hacks will cut over as we
Examples (Score:2)
Suppose you want to find the last names of people in your address book who might be Vulcans, and produce a list ordered by the length of their name (five character names, then four and six character names, then the rest, alphabetized within length groups
address_book. /.*k$/ }.
collect { |person| person.last_name }.
find_all { |name| (3..8).include? name.length and name =~
sort_by {|name| [[2 2 2 2 1 0 1 2 2][name.length],name] }
I'm not sure, but I think this would be harder in C#.
--MarkusQ
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
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".
Re: (Score:2)
Understand that I am a huge Ruby supporter, which is why I don't want to see unrealistic expectations about YARV that don't deliver, thus tarnishing Ruby's reputation.
Re: (Score:2)
If you search the mailing lists you will find results of experiments by Sasada showing VERY fast execution on examples using code the JIT compiler supports so far.
Re: (Score:2)
There are advantages to having a common JIT engine, though.
I've been sitting on the sidelines, watching all of this, wishing desperately for a clear winner. I'm looking for:
Re: (Score:2)
Common Lisp compilers:
I know that in all of these you can replace a compiled function at runtime with another compiled function,
Re: (Score:2)
I'm even more amused by LISP's parentheses, but I can live with them. I think of Ruby as exciting not because it's new, but because it's most of what I like about LISP without the ugliness. I mentioned Scheme because I seemed to remember it having a bytecode engine.
But the real problem seems to be the same problem as with everyone's pet language. In theory, LISP could do everything I want, but I can't find a single implementation of LISP or Smalltalk that does it. Well, that's not true -- I can find on
Re: (Score:2)
GCC: 1
Java: 0.8-2, sometimes upto 4
Smalltalk: 4-20, sometimes upto 80
This was against highly optimized cincom smalltalk, the fastest around at the time, and even on OO tests like method dispatch. And Ruby has all the same issues as smalltalk (dynamic dispatch, boundless integers, blocks/closures, etc).
Ruby, Python, Perl, Smalltalk, etc sometimes te
Re: (Score:2)
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)
No it isn't, it has been around since 1993.''
I meant it in a evolution, lifecycle kind of way. Ruby is still in a pretty early stage of life, and a lot of work can be done on improving the language and (especially) the runtime.
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)
And even then, the type system is still not up to scratch. E.g, there is no way to cast from Object to Map in a typesafe way. That is, you can cast, but the object might turn out to be a Map or similar. This is because the Java type system cannot carry around the parametric types.
Re: (Score:2)
I meant, of couse, Object to Map<String,String>.
Re: (Score:2)
Re: (Score:3, Informative)
AFAIK, The 6th major revision of the Java platform, codename Mustang, already provides a well d
Re:Bad News (Score:2)
I can see where this will lend to: a convoluted syntax more close to Java and less of the conciseness of Smalltalk and Perl...
Re: (Score:3, Interesting)
Re: (Score:2)
I actually find this to be the most promising aspect of this announcment. Not really surprising, considering the marketing speak M$ has been going thru lately regarding improving the CLR for dynamic languages, and what's happening with Iron Python (on
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.
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.
Re: (Score:2)
Re: (Score:2)
SCripting language support has been part of the spec for java6 since the beginning, mid 2005. JSR 270 [jcp.org]
Re: (Score:2)
To be fair, though, in technical terms the Common Language Infrastructure/Runtime was designed from the ground up with far more emphasis on language interoperability. The fact that this is having influence upon the Java creators is a good thing, and should not be dismissed so easily. The Java system itself is currently being changed to have better support for dynamically-typed languages and scripting languages in general, which is clearly the effect of the outside popularity of these types of language.
.NET
Re: (Score:2)
As long as it walks, talks, and quacks like C#.
As for closures, I'm a big fan, and I used to wish for their inclusion in Java. But I've come to reconsider that. Java is -- leaving aside for a moment the schizophrenia that is the primitive type system -- extremely object-oriented, at least in that it wants every user-defined type to be an
Re: (Score:2)
Support for Dynamic languages (Score:5, Insightful)
Re:Support for Dynamic languages (Score:5, Insightful)
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.
Re: (Score:2)
I am not saying it sucks but it does seem half assed to me.
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:2)
>If you're serious about programming, you've used or at least heard of Lua
Uh huh , whatever you say sonny.
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.
Re: (Score:2, Informative)
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
Sun has a lot to offer (Score:2)
So, we have a tight case there. Besides Matz is also working on Ruby2.0, which will have VM execution kind of stuff. So, though you may celebrate if you want, I would rather like to have C Ruby for my breakfast. There are two major problems of Ruby:
1. Slow (yes its slow and stylish)
2. GUI programming
And guess, what Jruby is not going to bring anything better on the table on these two fronts.
I disagree -- there are more problems with Ruby than just those, and they are things Jruby could fix.
The big problems
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:2)
They can't support every open source project and everyones favourite language under the sun. From what I have heard development on Jython is picking up again, and it performs quite well. Perhaps Sun thought resources were better spent on improving speed and stability in the core, so
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
JSP? (Score:2)
Re: (Score:2)
Not JSP itself, but you'll be able to write your servlets using Ruby. I think that eventually someone will even port ActiveRecord to JRuby, and you'll be able to use RubyOnRails inside your favorite servlet container, such as Tomcat, and have access to the best from both worlds.
You can already use scripting languages, such as Ruby, to write Struts' ActionServlets, just to give you an example.
Re: (Score:2)
Also, note that you can pretty simply get a similar effect using just pure Ruby, by using heredocs and interpolation, e.g.
print
#{some_ruby_code here}
EOT
Re: (Score:2)
Great, now if only... (Score:2)
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".
embrace and extend (Score:2)
I wonder whether Sun tried acquiring Jython first and was turned away...
Re: (Score:2)
Java is an OPEN platform, based on well established standarts that are made public, royality-free. Everyone is free to make their own implementation of the JavaVM, this commitment to open standarts made efforts like IKVM, Kaffe, Classpath and ohters possible on the first place.
Also, every bit of the Sun's Java implementation sources are avaliable. And every future modification on the Java standart is made public avaliable way before its deployed, including a refere
How long will it last (Score:2)
I love Sun, and I think it's great that they're doing this. I hope they prove me wrong.
Why not hear it from the guy who made it happen... (Score:2, Informative)
instead of speculating? Here's Tim Bray's blog post about hiring them here [tbray.org] and a follow up here [tbray.org].
from Tim's blog:
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.
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:2)
Re: (Score:2)
> ???
Let's take a look at some of the functions in stdio.h: "fputs", "getw", "scanf", "tmpnam", "ungetc". To a programmer who's unexperienced in C/C++, these names don't give the slightest clue as to what these functions are good for. They're unpronouncable, hard to remember, and syntax completion won't do you any good unless it also shows a short description of what these functions
Re: (Score:2)
Only an advantage in some areas. If you're writing a low level
caching algorithm such as for an RDBMS server or file system
driver you don't want the runtime deciding when to flush the
memory , you want to do it when you think its most efficient.
Java is an application programming language , its not for
low level code where you have to know what you're doing and
thats where C/C++ comes into its own.
Re: (Score:2)
Except that (C)Ruby works, is stable, is actually used (more than Jython I mean, which is used quite a lot), and is not designed by taking everything that looks shiny and shoehorning it in a stupid language.
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, Insightful)
I pick a 3d shooter. Now you get to pick anything less yawn inspiring than a database driven office app right? This is a fun game. ;)
Seriously though, each language has applications that it's well or badly suited for. Each moderatly proficient software developer s
Re: (Score:2)
Damn, where are my mod points?
You're absolutely right. Java and C++ are different tools, with different strengths and weaknesses. Attempting to compare them like-for-like is meaningless, as is making general statments about which language is "better".
If you want to do serious mathematical modelling, for example, you have a pretty limited selection of languages available. Most of them start with "C". Most of the others start with "M" and are written in languages starting with "C".
On the other hand, for
Re: (Score:2)
Actually I'd say Fortran90 is probably a better language for serious numerical computing than the languages you described: it handles array computations natively and parallelizes well.
Re: (Score:2)
Indeed, Fortran is one of the few other languages that's in the game. Whether it's still ahead of C++ on raw performance grounds is a bit of a moot point these days. Some class and template wizardry in C++ libraries now means heavily optimised data structures and basic algorithms are available, which negates a lot of Fortran's native array advantage. Also, things like the F2C conversion library now allow important Fortran-based libraries like BLAS and LAPACK to be built natively on C++ with all the optimise
Re: (Score:2)
Re: (Score:2)
And thus you illustrate why it's not successful. Let's pick a quick list of very successful languages:
Python
Perl
Ruby
Java
You know what this list has in common? An extremely powerful set of standard libraries. Hell, the whole reason I enjoy working with Perl and Java is because of the very rich set of APIs made immediately available to me (and in the case of Perl, this extends to CPAN, which is ridiculous in it's breadth).
APIs are the key. Without them, n
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Open Source folks will generally write in a language they're familiar with. For a lot of people, that's Java. I agree with you that the JVM is unnecessary complication in most situations, but the language itself is nice, with a large, cohesive, well-documented class library. Purely on a language basis, I prefer Java to C/C++. A lot of the time when I'm developing something for myself, I'm doing it more for the chance to muck ar
Re: (Score:2)
Java could, in theory, perform very well. In theory, it could perform faster than C. Remember, a VM does not necessarily mean slower, and there is something to be said for the portability -- Java was supposed to be AJAX, 10 years earlier.
Re: (Score:2)
Hey, I'm 40+ too, but I'm only 24 years old!
``to make a choice without regard of the inner working of their code, its requirements and the weight it will impose on the system or other
Re: (Score:2)
Most of us still get a little bit of an upchuck reflex when remembering the hype that Scriptics put behind it.
It still has lousy regular expressions, when the rest of the "quick-and-dirty" languages support PCRE.
Its OOP models are bolted on to a degree that makes perl look clean. Most of them don't even garbage collect objects, you have to free them yourself.
Its quoting model and its whole parser is weird and flakey. Everyone gets bitten by