Ruby On Rails Showdown with Java Spring/Hibernate 555
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?"
Re:Faster? (Score:5, Insightful)
Here we go again (Score:1, Insightful)
Re:Faster? (Score:5, Insightful)
any comparison like this... (Score:1, Insightful)
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
Not a safe or true assumption (Score:4, Insightful)
Anyway, in this particular case you may be right.
Re:Faster? (Score:5, Insightful)
Development Resources? (Score:3, Insightful)
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
You are all wrong (Score:5, Insightful)
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.
Re:any comparison like this... (Score:1, Insightful)
Reimplementing any app, changing the language or no, results in a better implementation, because the (re)implementor has a better understanding of the problem.
If he were to go back and redo the Java app in Java, it would be interesting to learn how it turned out.
Application (Score:5, Insightful)
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 [rubyonrails.com]
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
Re:any comparison like this... (Score:4, Insightful)
Regards,
Steve
Re:You are all wrong (Score:4, Insightful)
If you're the only one using a language, it can get pretty lonely. Plus, managers like technology that is generally popular in case you get hit by a bus.
Re:any comparison like this... (Score:5, Insightful)
The app he wrote was quite complicated, and he freely admits that Rails got some free jump-starting because of his understanding of the domain. But you're going too far in saying he'd get a 50% speedup from a rewrite. His Java codebase needs work, but not that much work.
He observed that the more complex the action, the faster RoR ran compared to Java. This is very counter-intuitive, so he went into an explanation of why.
Line counts, method counts.. all lies. (Score:2, Insightful)
Re:You are all wrong (Score:5, Insightful)
Not so.
There are purely functional languages that are -- for all practical purposes -- impossible to optimize as well as either procedural or hybrid procedural/functional languages.
However, that's beside the point. Java in particular is NOT just a language. Java is a specification for a fair amount of the IMPLEMENTATION as well. Java specifies the behavior of GC, type storage, and many other implementation details ot a level that precludes many hardware or OS specific optimizations.
There are non-conforming compilers that ignore these strictures (and get excellent performance), but they are not -- strictly speaking -- compiling Java.
Languages like Ruby, Python, Perl and PHP on the other hand, make no such strict demands, and thus can be optimized appropriately for the platform.
Ruby marketing vs Cherrypy (Score:2, Insightful)
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 [cherrypy.org]. 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.
Damn stupid summary format (Score:3, Insightful)
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 too hyped (Score:5, Insightful)
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.
Re:Wait..... (Score:4, Insightful)
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.
Re:You are all wrong (Score:1, Insightful)
Oh, and read Boquist 99, I think it covers producing optimized code for lazy functional languages.
Second Time Around (Score:2, Insightful)
Re:Hibernate too hyped (Score:1, Insightful)
Re:any comparison like this... (Score:3, Insightful)
Re:Security (Score:5, Insightful)
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?
Meta-application issues (Score:4, Insightful)
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.
Re:You are all wrong (Score:2, Insightful)
So, as you imply yourself, a language can be measured by speed.
Most programmers would say that assembler loses out in each of your above criteria, yet it is still used for certain tasks. Why? Because it is quicker.
I agree overall with what you are saying, but the world isn't quite as simple as you make out.
Is it just me or... (Score:2, Insightful)
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.
Re:RoR == the mysql of web servers (Score:3, Insightful)
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.
RoR sounds great, but... (Score:5, Insightful)
Wrong attitude. (Score:2, Insightful)
Re:Meta-application issues (Score:3, Insightful)
It's not like C++ (which, in my experience, takes a LOT of training in order to become proficient).
Application scaling (Score:5, Insightful)
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.
Hardly (Score:3, Insightful)
Re:You are all wrong (Score:3, Insightful)
Out of the box (Score:3, Insightful)
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.
Re:Meta-application issues (Score:3, Insightful)
(raises hand) Pick me! Pick me!
Seriously, I've been programming in Ruby for a few years now (sometimes even getting paid to do it). It's so much nicer working in Ruby and there are quite a lot Rubyists out there who would love to get paid to develop primarily in Ruby.
Also, anyone who knows Perl, Python or even C++ should be able to pick up Ruby in a week. Companies are often too concerned about findind someone with an exact skillset that they overlook a candidate's growth potential.
Re:You are all wrong (Score:2, Insightful)
C++ is not even a tool option for a wide variety of embedded architectures. Existence is a very big benefit.
Re:Hibernate too hyped (Score:3, Insightful)
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.
And what does this have to do with Hibernate? Last I checked it doesn't generate SQL schemas for you (although you can get an add on to do it if you want.)
Also, you can tell it the exact SQL expression to use if you find that its not doing something right or you need to "tune" it. Of all the times I've used Hibernate ojects, I've never had to do this.
Re:Security (Score:3, Insightful)
Oh look, the shell lets me type rm -rf. I better stop shell programming.
The tutorials are sloppy. This doesn't mean Rails is.
Re:You are all wrong (Score:3, Insightful)
I am not an advocate of either C or C++, especially for just about every type of software that runs in userspace.
That said...
Even I, the non C advocate, recognize an advantage of C over C++. In C you can "see" every single clock cycle in your program. If you pass a pointer into a function, then inside that function, you can "see" the dereferences. Every single operation that costs cpu time is vislble as some kind of operation / operator in C. No hidden array bounds checking. If you check array bounds (yourself), you can see it happening. Absolutely every single clock cycle exposed in the source code for everyone to see.
Therefore, and also because of the portability of C compilers, C is a great high level and portable "assembly language".
As an "assembly language" it can be targeted as output of other compilers. Imagine the portability of huge mountains of software if only a simple C compiler has to be ported to a new processor architecture in order to initially get a bunch of stuff working. Remember that TinyC compiler that could recompile the entire Linux kernel as part of the boot process, in only about 15 seconds?
Conclusion holds the key (Score:4, Insightful)
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.
Not convinced (Score:1, Insightful)
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.
Re:Here we go again (Score:3, Insightful)
Depth is far more valuable than breadth, especially in a real corporation. In a real corporation, the objective is to make money, not see how many different disparate technologies can be strewn around and later supported for the next 10-15 or more years. The objective is also to get the job done as quickly and efficiently as possible. If Java does the job better than than Java gets chosen for our enterprise project. If Java and do the job equally well, but we already have a Java programmer and not a programmer, then Java gets chosen. Every minute you spend barely getting deeply involved in a language, such as you claim to do in your first post, makes you more useless to a corporation, not more useful.
From an educational standpoint, I agree than both depth and breadth are of utmost importance. But from a business standpoint, I completely disagree with you.
Re:Hibernate too hyped (Score:5, Insightful)
Perhaps you should try actually using Hibernate.
First, Hibernate works just fine with hand-generated SQL tables. Indeed, that's the only thing I've ever used it for. Second, you can happily tune your queries through hinting to Hibernate and careful choices of object relationshiops, and the recently released Hibernate 3 allows to you hand-write all the SQL if you choose.
Third, you're kinda missing the point of Hibernate. Using Hibernate akin to using Java itself in that both of them hide a lot of details about the underlying operations so that the programmer can spend their time and energy focusing on the essential problems rather than the details of the technology.
Most programmers doing SQL stuff in Java let the weirdness of SQL databases distort their designs heavily. They don't really do OO programming because they spend all their time thinking about database operations. Hibernate lets you do good OO design and have 95% of the SQL rituals handled under the hood.
It's possible that you lose some performance to Hibernate, although I never noticed it, and Hibernate's built-in caching [hibernate.org] means that many apps will be faster [hibernate.org]. But really, if performance is all that important to you, you shouldn't be using a database at all. Serializing all your data every time you need to work with it is incredibly expensive. There's a reason that things like Google and Quake aren't built on top of SQL databases.
I think this is great news (Score:3, Insightful)
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.
Chill out horny rails guys. (Score:4, Insightful)
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.
Re:Here we go again (Score:3, Insightful)
What I was simply saying is that in your first post you very much sounded like you were bashing people who are intimately in-depth with one particular language. Especially if those people resist learning 20 new languages simply for the sake of having to learn them. That is a waste of everyone's time and money, especially if the project can be accomplished in the language the programmer is most comfortable with and happy using. Not everyone's reason for resistance is 'protecting their turf'. If you are trying to talk specifically about some people who you know, in a very finite view, then that is fine.
Personally, I love to program in Java and would move most of our corporation to the platform if the opportunity were to present itself. In a small generalist corporation, it may be beneficial to have 20 different programming languages being learned on a superficial basis by 20 different people, none of them experts on any one particular field. Generally, but not always, you get what you pay for in the end product with a group of people like that too. You've heard the saying "Good at everything but exceptional at nothing". Like I said, that does not apply to everyone as some people can be absolutely exceptional at anything and everything they want, and those people are exceptional talents, but you get my point. In a much larger corporation, such as the one I currently work at, software goes into production cycles on scales of 10-15 years. In-house talent and support dictates how projects get implemented. A very small, finite number of excellent programming languages, a small group of programming language experts, and reuse and homogenization at every possible step saves not only time but money.
Intelligent people are not just the ones who are the most flexible, but are absolutely the ones who are the most singular and focused on the job at hand. And on top of it, if they are passionate about their work too, then more power to them.
I agree that with your point that learning should never end and that adaptation and flexibility is key to growth. But, you need to learn respect and be understanding of those people who are most in-depth in their work too. On your point about flame-wars being stupid, I completely agree.
Re:You are all wrong (Score:3, Insightful)
You're being abusive. This will be my last attempt to communicate with you in this thread. Clearly, you're not interested in the topic so much as
"You don't know what you're talking about."
Last refuge....
"Functional languages are *easier* to optimize, not harder."
You're confusing terms here.
First off, you're obviously correct. A purely functional language is much easier to optimize than a non-functional language.
Of course.
Now please go back and read what I wrote. I was speaking of the end result: execution time (presumably on modern hardware). I'm going to repeat myself at the end of this message for the third and final time. If you still have trouble understanding the difference between what you're saying and what I'm saying, then I'm afraid I can't help you.
It's very easy to perform many sorts of near-optimal transformations on a functional program, and while there's deminishing returns here, there are in ALL programming languages (perfect transformation of a grammar into its optimal form, is of course, known to be a hard problem, but that's not dependant on the language in question).
Now we get into that ugly bit: when you take your code and plunk it down on modern hardware, you find that your program performs poorly! This is because modern hardware is fundamentally NOT functional in nature. In fact, it's quite assertively operational!
So now you have to take your near-perfectly optimized functional specification for a program and transform it into an operational instruction set. There are, of course, many ways to do this, and it turns out that finding the optimal one is actually much harder than having performed simple functional transformations on your code in the first place.
There are other reasons that MOST functional programming languages cannot reasonably be optimized down to code that out-performs, say C, but they're all a matter of choosing to be a high-level language, and other high-level languages suffer the same problems regardless of how functional or procedural / operational (e.g. in a language with dynamic types).
There, I've repeated myself. I hope this helps.
If you consider anything in this message to be other than well-established fact at this point, then please provide a compiler which compiles ANY functional language down to machine code such that compile time plus execution time is less than or equal to that for the equivalent C program and gcc with normal (-O2) optimization.
If you're still confused as to how any of this could be possible, sit down and write a translator between your favorite functional language and C. That should explain a lot.
Re:Part of the Reason (Score:1, Insightful)
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.