Slashdot Mirror
Ruby On Rails Showdown with Java Spring/Hibernate
Paradox writes "Java developer Justin Gehtland recently tried re-implementing one of his web applications in Ruby on Rails instead of his normal Java Spring/Hibernate setup. His analysis of overall performance and application size was startling, to say the least. The Java app's configuration alone was nearly the size of the entire Rails codebase, and Rails application was significantly (15%-30%) faster! At the same time, the Ruby community is abuzz because Ruby is getting a new optimized bytecode compiler for its upcoming 2.0 release. Will Ruby on Rails become even faster as a result?"
theres a difference between compiling faster and running faster. If the "optimized" compiler merely spits out the same bytecode at a faster rate, applications will start faster and any JIT compilation done will be faster, but a continuously running application will eventually operate at the same speed as before. If it spits out "better" bytecode, then we'll see speed increases.
Nothing like fanning the flames of an already hot topic between J2EE & RoR developers. Just watch, it's impossible to have an intelligent discussion between the two groups.
Optimized means that it's doing something better. Smaller binaries? Less memory when running? Faster execution? Faster to compile? In the context of the article, you can assume it's about speed. But out of context, you cannot.
-
ping -f 255.255.255.255 # if only
...
/overengineered / whatever? Ruby on Rails MAY be much better but any evidence like this is hardly valuable, that's why I would not even bother to RTFA
without reading TFA, any comparison of this sort does not have much value. Maybe if he reimplemented his app using same Java he would get 50% speed and codebase improvement? Maybe the original was just too poorly coded
...remember good 'ol times when IP used to mean Internet Protocol....
It all depends on what you are optimizing for - you can optimize for size, for instance (smaller but slower applications). You can optimize for portability and end up with code that is both slower and larger (but more portable). You can optimize for almost anything you need. Speed is one factor only.
Anyway, in this particular case you may be right.
Yeah, an optimized compiler isn't the same thing as an optimizing compiler...
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
How much time did it take to develop the site compared to Java?
I ask here because the site is dead, Ruby isn't a magic hammer after all.
Pete
There have been many posts concerning the speed of each and every possible language. Some have gone as far as to link to several studies with nice charts and graphs to conclude that X language is faster or X1 is truly the fastest. You are all wrong.
A laguage, in of itself, cannot be measured by speed. A language is merely a group lexical elements with a particular syntax. That syntax has an associated semantics to it. That is it! It is pointless to compare languages purely on speed.
Now, what we can compare is the implementation of a particular language. For example, we can compare the speed differences between the intel compiler and gcc for the same piece of C code. We might find that in most cases, gcc is slower that the intel compiler. Does this mean that C is slow? No! Now, take the same algorithm and port it to Java. Lets imagine that the Java version was 10x faster. Does this mean Java is inherently faster langauge? NO! It means that the compiler, JIT, and HotSpot implementations are better at tranlating Java source code down to the machine level.
So, in summary, a language by itself should NOT be measure in speed. It should be measured by the following:
Maintainability
Ease of Use
Learning Curve
Clear Semantics
Support
Documentation
Standard APIs
Most often, when languages are compared, you are merely comparing the differences in constants in a language! Lets say we implement the Quick Sort Algorithm in C++ and Python. We will probably find that the C++ version is slightly faster. What does this mean? It means the the implementation of C++ generates fewer constants that the Python Implementation. So, the Python version may be slower, but it is only in constant O(1) differences and in most cases this does not matter! Eliminating extra constants ( in any language ) is stupid when you have chosen the wrong algorithm in the first place! ( such as an order n^3 when it could have been n*log(n) ).
So, what is the moral of this story? Pick the right langauge for the right job. It you are doing advanced GUI development and prototyping, C++ is probably not the way to go ( since it is harder to write fast and correctly ). However, it you are doing low-level real-time I/O where constants do matter, then C/ASM is probably the way to go. After you have chosen he right language for your task, you must choose the right algorithm! Algorithms are the key! Algorithms are the only true way to measure the efficiency on any program in terms of memory and speed.
Speed is a stupid mesure for web apps. There is nothing easier to scale then webapps in the world. You can cope with any amount of traffic by just throwing more hardware on the problem in a share nothing environment like php, perl or ruby/rails.
Whats interesting is the development speed and thats what the comparison between the java and the rails version highlighted well. For a great analysis look here: weblog
What makes the above link so special are the comments from the java community saying that the two examples are not functionally equivalent. This is really golden because they are really not. The rails version ( which is 3 lines of code ) does everything the java code does plus tons and tons of more things just by taking educated guesses after looking at the SQL schema.
Rails is a remarkable framework and a glimps of what programming will be like in the future. Yarv will just save some hardware costs
--
First they ignore you, then they laugh at you, then they fight you, then you win. -- Gandhi
Oh please.. Author talks aout line counts and method numbers.. You count getter setter methods? you count the lines for {} symbols and getter-setters? You know that they can be produced lets say in 3 seconds with any modern Java IDE.. it has no meaning what so ever to put them into consideration in terms of productivity.. sigh.
15% - 30% faster! Wow. I hope anyone who ever developed anything for java is reading this so that they can start reimplementing all their code right away.
Another showdown I'd like to read about is that between Rails and Cherrypy. Not in terms of technological superiority, but in terms of marketing skill. Why is the web abuzz with Rails, while Cherrypy is almost unknown.
This isn't flamebait. I'd really want to know how they did it.
http://flosspick.org finding the right open sour
Does this mean the code will be faster?
What does the Slashdot community think about that?
Is this the end of free software?
This whole damn site is a discussion site. What does "What do slasdotters think about this?" add? Especially bad is the monthly article on total cost of ownership or the invalidity of the GPL ending with the "Is this end of FOSS?"
Hibernate seems to be the most hyped technology for webapps on java right now. I evaluated it to use it on my thesis.
.xml file and use them with very few lines of code. It maps the results of the queries to your javabeans. Really simple, but powerful, there's a whole way of doing dynamic queries (i.e, if some object exists, do something with it, else don't)
I don't trust/want something to auto generate my sql tables and such based on my objects. That leads to problems, since the queries can't be tuned or maybe you don't get what you expect.
So, i am using SqlMaps. You put your sql queries in a separate
Disclaimer: i don't have any relationship with sqlmaps, i am just a happy user.
Open Source Java Web Forum with LDAP authentication
Java as a "dynamic deployment platform", as you put it, offers trivial matters such as load balancing, server-independent sessions, and hot deployment (where new sessions get the new codebase, while old sessions get the old codebase), just to name a few. These three items alone are nearly impossible to pull off in a PHP/MySQL configuration, without keeping your sessions in a database and reloading them for every single pageview. Nearly every Java app server gives you these without having to write any code.
And I think that's where a lot of these pseudo-flamewars get started. On an individual page basis where all I'm doing is "SELECT * FROM NEWS WHERE ID = ?", on one machine, of course PHP and MySQL are going to run faster. But once you start deploying your application to multiple boxes, the advantages of Java become clear.
Additionally, I would challenge you to this test: let's say you have a stock PHP installation, without the GD libraries linked into the PHP binary. Now let's say you want to create a PHP application that uses GD. Do you A) recompile your PHP server, or B) give up platform-independence and run some kind of system call? Under Java, the answer is C) add in a GD jarfile to your application, and you're done, without any recompilation or configuration on your part.
My point, and I do have one, is this: in exchange for the inefficient startup time of the VM and potentially inefficient bytecode (depending on your app server-- Tomcat is a real dog in this aspect) Java gives you a ton of freedom. With hardware getting faster every day, I'll make that tradeoff every single time.
Every time a good coder rewrites an app, it gets better. Especially a large, complex app. Ususally the new design insights afforded by a "warmup" cycle have to battle the tedium of repetition. But rewriting in a new language, especially one in which you're fluent, and interested in exploiting for performance, is a real motivator for optimization. I'd like to see comparitive benchmarks for another rewrite, *in Java*, to see how much performance gain is from the language, and how much is from the educational rewrite cycles. Deriving the motivator of "interest" is going to be harder, though still a factor.
--
make install -not war
Dear Moderators,
THIS IS NOT INFORMATIVE. It is INTERESTING. If the poster had supplied supporting evidence at all, it would have been a start towards informative.
As it is:
1. Which tutorial was it?
2. Was the problem a fundamental problem with Ruby on Rails, or the tutorial itself.
3. If it was a problem with Ruby on Rails, can it be fixed?
Improvements in performance and application size are always welcome, but there are some important outside issues to consider when picking a platform for your project.
One is, how deep is the library? With Java or Perl, there are libraries of open-source tools such as Apache Jakarta Commons and CPAN that often mean that with a quick download an enhancement request is 80% done. All new platforms (naturally) have a disadvantage in the department.
Another is, how easy is it to find developers with applicable skills? If an organization commits to Ruby and their Ruby developer leaves, how hard will it be to find a suitable replacement? This is a problem for all platforms except the juggernauts like Java, but especially new platforms. Looking at this another way, a platform choice can be a multi-decade committment. Choose carefully.
So the summary of the summary of the summary is that software development doesn't take place in a vacuum. Ruby is the coolest scripting language ever, but I can't recommend it until I learn more about its library and community.
org.slashdot.post.SignatureNotFoundException: ewg
Nowhere in the article it is claimed that the "The Java app's configuration alone was nearly the size of the entire Rails codebase".
What is said is that it's the configuration files are nearly the size of the ruby implementation of the example application.
I know that rails makes you write less code but don't over do it.
The funny thing is you obviously didn't read the article, where the author noted that Java was faster for the less-complicated things but the more complex the pages got the more that Rails kicked ass.
Considering that this guy wrote the Spring: A Developer's Notebook for O'Reilly, I'm inclined to believe that he has a clue when it comes to the Java side of things.
I've been meaning to try out some RoR development for a while now, it looks like an incredible language. That being said, I keep thinking of something I read on another forum - don't trust a language until someone can explain to you why it sucks. Right now RoR is in full hype mode, with 100% gushing and not a lot of discussion of its weaknesses, things like that. So that being said, can anyone tell me why RoR sucks?
This is why I gave up on rails. The developers take the attitude of "its your problem, you make sure its secure". No, that's wrong. You are making a web development framework, then YOU make it secure. If you don't read the rails code and find out how things are implimented underneath, then you don't know if your own code is vulnerable to SQL injection or not. That's rediculous, all the rails automatic SQL generation should be safe, you shouldn't expect every user to guess which is the safe way to use rails and which is the unsafe way. And when David dismissed a patch to fix an issue like this "because that would inconvenience people who are using the potentially insecure method securely", I knew he had no business writing software for the web.
You know, I've made a tone of cash begging to differ with this. Perhaps you should ammend that statement to be "There is nothing easier in the world to scale than trivial webapps".
First off, a webapp is not a peice of code on a web server; it is a functional system that does desirable work. Yahoo Search is a web app, but I'd be really impressed if it ran on one server. The front end may be easy enough to scale out, as long as you've figured out how to effectivly manage session handling (either by not using them, having the state kept on a 3rd party system, or assigning a session to always go to one web server).
Now, if we're talking only the front end part, than it makes it a whole lot easier to scale out by throwing money at it. The problem I've always run into is the various resource utilizations on the web server.
If your webapp calls up an application framework and calls up a ton of copies of it, or even just takes up a lot of memory, you run out of it, which now asses a 10,000% penalty on access thanks to swapping. You won't see this if the framework requires a couple megs, and is going to be pooled in some way, but it suddenly gets real interesting when you have hundresd of copies floating around (for whatever reason). When this happens, you now need to know how much of a monetary hit you take to get it to an acceptable level. It may just end up being way too much cash spent to get you to the next level. Then you may have to do it again.
I wound up doing a job that each web app used about a gig of RAM if it ran long enough. I told them to fix the leak. They said the programmer just quit. So we throw money at it. They ran up to 60 web apps on Windows. Guess what.... it would have taken $20,000 and a bunch of downtime to do the upgrades. Once the guy stopped yelling, he realized they were forced to fix the app.
Same priciple applies to anything that hits the disk more than it should, tries to factor large numbers, or tries to download all the Internet porn right now. You run out of something, and have to either see if you can spend money, or fix it so it should have to.
Basically, if you've got a simple app, it's easier to throw hardware/money to scale it. If your app is a large system with complex requirments, it may be possible to do that to an extent, but it's much better to have different tools that may provide much better results.
- Dan
Speed is important, but not the most important thing. If that were true, then your Browser would not be written in C or C++, but in Assembler.
Yeah, right.
Java is an old man in todays hyper-development environment. Teh old man still has a few tricks up his sleeve though, and he can get the job done. He's just not the upstart he was in his youth.
CS is CS -- there's more to development than language. In 10 years Ruby will be supplanted as well -- and we'll be talking about the NEXT great language.
Face it brother developers, in this profession, we cannot sit around and become complacent. Learning a new language is somethign you should do joyfully. All my pay work in still in Java, and I don't anticipate that changing -- but I thinkI am going ot move some of my pet projects to RoR -- just to see what it's like.
Nothing great was ever achieved without enthusiasm
Funny, I don't recall JSP templates scanning for javascript and rejecting them. How is this ROR's problem? You get the same thing in JSP, ASP.NET, PHP, and anything that lets you substitute values from the environment.
Oh look, the shell lets me type rm -rf. I better stop shell programming.
The tutorials are sloppy. This doesn't mean Rails is.
I am no longer wasting my time with slashdot
This whole thing is easily blown out of proportion, in the opinion of the author. Pay attention, people! Use the right tool for the job- all this guy is saying is that in his one instance, he found he was working on a simple project in which the caching of Ruby on Rails worked very well.
Measurable slowness of individual functions in Ruby were overcome by an agressive caching scheme. It's entirely possible that similar or better results could be had in Java, but it would take effort. YMMV. More than a few more comparisons might be needed before you decide to dump Java for Ruby. Think and test. He's just relating a positive experience with a new tool- one which contradicts many people's assumptions about the speed of Ruby as a deployment solution. It's one interesting datapoint, and a fairlly anecdotal one at that... nothing more. I'm definitely not saying it's not significant, but it is what it is, folks shouldn't make it out to be anything more.
I have nothing to say about the cache performance differences except that a 15-fold increase cannot be explained by language choice but must point to algorithmic and library decisions.
But more importantly, the reason I'm not convinced is that the author's methodology is rather unsound. He took a first-generation Java application and *reimplemented* it. When you do that, you get to add in all sorts of improvements that you hadn't thought about the first time around. You're not so close to the trees any more. It's entirely possible that the improvements in performance and number of lines were largely due to the fact that he wrote a second generation rewrite, and had less to do with the fact that he wrote it in Ruby. Ruby is a significantly slower language than Java -- I don't think even RoR advocates would debate this. Isn't it possible that the fact that he got his RoR code to run as fast as Java in non-cached mode due to second-generation improvements which countered Ruby's natural computational pokeyness? And the cached mode improvements due to his choice of library?
You can write dang fast stuff in Java if you're careful (and sacrifice Sun's stupid slow libraries). It's not nearly as easy to write dang fast stuff in Ruby or Python. Indeed, all one really can say about them performancewise is that they can outperform highly lazy code in Java -- which is of course what the vast majority of Java coders write, so maybe that's not so back-handed a complement as it sounds.
I hope this inspires a lot of people to use Rails in demanding production enviornments. That way after they have picked the arrows (if any) out of their backsides, the rest of us can follow along. In all seriousness, I'd be on the rails bandwagon right now if it had a bit more of a track record, and if certain highly specialized java libraries I use were available in ruby.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
He asked what sucks about it. I told him. Seriously, nothing is perfect, including your precious rails, get over it. The list is only three items long, you should be proud, not trying to make up excuses.
l s/749/match=sql+injection
I think I formed my opinions before the 0.10.0 release too. I tried what was being hyped as the greatest thing ever. These were the problems. Sorry you don't like it, but that's what I found. There has been no indication of a change in attitude with regards to security:
http://article.gmane.org/gmane.comp.lang.ruby.rai
and a simple scaffolding blows up with the current version of rails for me, so I think clearly the mysql specific issue has not been dealt with sufficiently.
As for speed, benchmark ruby yourself, its recursion is an order of magnitude slower than other languages, PHP being the other language sharing this undesirable trait. And benchmarking rails vs some mess in tomcat doesn't mean anything about rubys performance. Benchmark ruby and java, java is WAY faster. I don't think this is that big of a deal, but you can't deny that this is one of the weaknesses rails has in it, which is what the poster specfically asked for. Everything has its downsides, and wanting to know about them from the start is a pretty smart move.
Hmm, HTML, javascript etc are not programming. And as far as "all these college kids learn now-a-days is java" posts, that is total crap. The paticular language is meaningless, it is the concepts behind CS that are important, not the flavor of the month language. Heck, MIT teaches its intro courses (until sophomore year I believe) in scheme, which outside of AI, is used by no one.
So I repeat, the language doesn't matter. If someone just out of school is any good, any good at all, then he or she can jump from one language to another with no paticular attachment. Maybe after 5 years stuck on the same language (I'm talking to all you C people out there), then there may be a reluctance to learn something new.