Something interesting has been happening in the blogosphere over the last few days. It seemed to all kick-off with Rick Hightowers post on Why Syntax Matters. It seems a mini-backlash is brewing against the Ruby hype.
Rick feels (and this is his opinion) that Sun should ditch JRuby and support Groovy because the syntax and migration path is so much easier for Java developers. He and several commenters on his blog, feel that Ruby is too different to Java. The post was features on JavaLobby and InfoQ.
This is of course the main reason I was sold about Groovy as it eliminates the context switching between languages as they are so similar, but a blog post that got me thinking the most was Cedric's entitled I'm not Tired of Java Yet. And you know what? I agree with him.
Unlike Ola Bini (JRuby committer) who is repeatedly questioning Java, I love Java and still believe it is a great language for many common tasks. Its just not great for everything. In the past Java was seen as "the one language to rule them all". Now as alternative languages like Groovy start to mature, its about picking the right language to solve the problem at hand and that tool is often Java.
Things like processing strings, doing really dynamic stuff and heavy manipulating of collections can get painful in Java. However, its death is highly, highly exaggerated. One of the reasons I believe so strongly in Groovy and Grails is that it is not about ditching Java or the Java platform, it's about embracing it.
Groovy supports true polygot programming when combined with Java thanks to the seamless way they integrate with one another. I, and most Groovy programmers, still love programming in Java and have no plans to ditch it anytime soon. Use each language when it makes sense. It is about using the best tool for the job.
21 comments:
Unfortunately, Groovy has serious design problem for really enterprise applications. Here is an excellent deep analysis:
http://www.huxili.com/index.php?cat=reports&id=ID000188
As I pointed out in the comments on another blog post that article is complete nonsense.
A) it provides no code examples
B) the problem is almost certainly because the test is using the same GroovyShell instance for each iteration which never allows the classes to be garbage collected
You can't carry out a valid test without first knowing the language idioms. Groovy is a compiled language, JRuby is interpretted.
It is quite trivial to find examples that put into question JRuby's readiness too:
http://groups.google.com/group/jvm-languages/browse_thread/thread/af8838607b60cc0b/e7f3247409b57f19?lnk=gst&q=600mb#e7f3247409b57f19
However I don't go splurging them all over the place with the aim of spreading FUD.
I totally agree! The Java like syntax is what sold me on Groovy as well.
It's just sad that so many people have written silly "Ruby is 10x faster to program in than Java, drop Java now!" articles. It's because of these people that Java people feel they have to write other silly articles saying how Ruby sucks so bad.
I'm a Java developer, who is also a Ruby developer. I really never saw myself as choosing Ruby over Java, as they do have some overlap, but are better suited for different things. Ruby for me, replaced Perl and PHP (it was a toss-up between Ruby and Python for me) as my dynamic Unix-centric language of choice.
I'm very happy using JRuby as it lets me use Ruby for what it's good at and then I use Java for what it's good at. I also use Ruby for all my server scripting needs, as well as my DSL needs; it would be painful to do either of those tasks in Java.
Add SQL and Javascript to the mix and you have all the languages I use on a daily basis.
Groovy is cool, but the reason I use Ruby is precisely because of the syntax; for what it's good at the syntax is a very good fit. But of course everyone's mind works different and perhaps for you Groovy or Python "click" better. That's why we have choices.
My 2 cents.
Ricks comments are closed when I've look some days ago.
So:
+1 for ditching JRuby.
Peace
-stephan
@Stephan
Again I must say that is not my opinion (ditching JRuby), but certainly more help for Groovy (NetBeans IDE, other integrations etc.) would be welcome
For the record, JRuby is actually compiled as well. It seems like it's an interpreter in the same way that the Groovy "interpreter" seems to be such. What it's actually doing is JIT compiling under the surface. This has ups and downs in that it has a naturally faster startup time than Groovy's (since it's not compiling *everything*), but of course the downside is slightly reduced performance in the first few iterations. Amortized over an application lifetime, the theoretical difference between JIT and AOT-in-interpreter is negligible.
Also for the record, if you look in the JRuby 1.1 distribution, you'll find a "jrubyc" script, which runs the JRuby compiler and generates Java .class files just like "groovyc".
Graeme could I make a suggestion:
Please stop (or at least throttle down) going at other languages. When I look at the last posts in your blog, about half of it is about throwing knives at jruby.
Be more positive, sell Grails with arguments, there are plenty of it. I know that you are emotional about it, but hey: this baby is good, rest assured that groovy/grails will have an impact.
Stand tall
In Graeme's defense, I don't see him taking pot shots at JRuby very often. He's obviously biased against it, but don't we all have our pet biases? I've seen a lot of language flaming in my time, and not too much of it from this source.
@chrigel
Thanks for the advice, but I'm not sure where I ran down Groovy in my post
I merely stated why I like Groovy and refered to other posts. I even said it was not my opinion that JRuby should be ditched by Sun
In this case there are no knives.
@daniel
JRuby is compiled in parts, but there isn't a one to one mapping between a JRuby class and a Java class like there is in Groovy
There are also times in JRuby when code can't be compiled. This is never the case in Groovy, it is always compiled
Sorry that should have read ran down JRuby of course ;-)
I think the point of Sun's support for JRuby is being missed. It's not about supporting one language versus another. It's about expanding the userbase of the Java JVM. The wider the language support the more reasons to use a Java app server.
There is room for a wide variety of programming languages in the development world. Each has it's strengths and weaknesses. Each solves a set of problems. Some overlap, some don't.
Sun may not want to support languages that explicitly work to replace Java. But, I see no reason why they shouldn't support JRuby AND Groovy AND Scala AND whatever else. If Ruby (and Rails) is all hype, it will die off soon enough. If Groovy (and Grails) have merit, they will find an audience. Why pit them against each other? Let the developers choose the tools that solve their problems.
I'm sure Sun will support the languages that further their agenda of selling servers, running the JVM.
I agree with you here Craig, supporting Groovy isn't going to sell them anymore hardware, because Groovy developers are already Java developers.
Shame most Ruby developers are part of small shops that can't afford Sun's servers ;-)
@Graeme: If they have enough willpower to keep focus and to support two languages they should do that of course.
But I have the feeling this is a zero sum game. And for strategic reasons Groovy is better suited to keep Java developers on the plattform for years after Java.
Peace
-stephan
Dear Anonymous #2,
RE: "...It's because of these people that Java people feel they have to write other silly articles saying how Ruby sucks so bad."
For the record, I never said anything bad about Ruby other than I did not much like it and felt supporting Groovy should be the priority since it would be a more natural choice for the Java community than JRuby more or less.
Hardly a stinging expose against Ruby. I never wrote "Ruby sucks". In fact, I said quite a few nice things about Ruby.
You like Ruby... Program in Ruby.
I'd rather see Sun support Groovy and Jython. I'd prefer they drop support for JRuby.
--Rick Hightower
Graeme: JRuby can compile any Ruby code to JVM bytecode. JIT compilation is the default runtime mode. In what way is it not compiled?
Ola, I haven't been keeping up with the times, Charles told me you guys were 100% compiling to byte code since November
Sorry I am a bit behind :(
Apologies for the mistake
So what makes the Groovy so threatened by the JRuby or any Ruby?
A language will be use for whatever reason and until you are Sun CEOs
you do not get to tell them how to toss the money. So Sun puts a couple hundred G into an open source project that actually gets them a multiplier effect of many people working on a Java project. Sun probably spends more $$ on
McNealy's car.
Maybe you should be trying to show Sun (or someone) that Groovy is worth backing. I am sure that attacking Sun is the right track.
Keep insulting Sun's move to open source and JVM platform development, that will surely get the financial support going for Groovy.
And any other company will surely back you guys. You seem like such nice folks, certainly not the type to be back-stabby-green with jealousy.
Groovy's main problem is also its biggest strength. It's too much like Java. You also, can't run Groovy without a JVM. Unlike, Ruby which can run with or without a JVM. The importance of this should go unnoticed.
Also, the JRuby camp has been very supportive of other languages, like Groovy. The Groovy camp should follow their example.
I am so happy to get some Atlantica online Gold and the Atlantica Gold is given by my close friend
who tells me that the Atlantica online money is the basis to enter into the game. Therefore, I should buy Atlantica online Gold with the spare money and I gain some cheap Atlantica online Gold from other players.
My father was very like to play the Aion, but he do not know how to buy the aion gold, so I know a website sell the cheap aion gold, in here I can buy aion gold. it is easy.
Post a Comment