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:any comparison like this... (Score:4, Interesting)
The lesson here I think is that unless you plan on running on multiple containers and using asyncronous calls java is overkill.
If you do need those things then ROR won't work at all.
Another thing is that ROR wants you to design the database from scratch to fit it's naming rules. It's not really designed to work with existing databases. For example it can't map the ugly database field names into nice attribute names for your objects. To me that's a pretty big shortcoming.
Horses for courses (Score:3, Interesting)
It's a little bit like using something like MS Access. If you play along with MS Access, and don't try and do things that it doesn't do particularly well, then you can actually build desktop database systems very quickly. If you try and go outside of the "Access way", it becomes a quagmire.
There are tens of thousands of sites out there that don't need to have queues, SOAP, RMI etc. They might be someone's list of restaurant reviews or something. Maybe RoR has a good place for that.
Re:You are all wrong (Score:1, Interesting)
Java is slow. How much of this is due to the nature of the language, and how much due to its implementation? I dunno, I really don't know much about Java. I do know that every interactive Java program I have ever used has been hilariously, stupidly, ridiculously slow. Practically speaking, the point is, right now, if performance is a significant issue, Java is not the right choice.
I disagree with this nonsense about "C++ is not the way to go." C is almost never the right choice. Most of the people currently writing C would be better off with a much higher level language (whether it be Python, Ruby, Lisp, whatever), and the rest would be better off with C++. Exactly what do you gain by using C rather than C++? Nothing. C has NO benefits over C++.
(In case it wasn't clear, I do agree that performance often isn't the issue that people think it is.)
Re:Application (Score:1, Interesting)
For a great analysis look here: weblog [rubyonrails.com]
You call that an analysis? You must have serious problems.
And please tell me what the Rails version does more. I'm very interested. The Java version does more imho since it uses ordinals for every entry and keeps them always ordered, the Rails version sets the ordinals to null if the entries are done and relies on the database natural ordering.
Screenshots like this are totally useless since they compare things that can't be compared. Rails handles lists well because it was written for Basecamp that does to-do lists (and more). So of course it's shorter since the functionality has simply been moved to the core framework (Acts -> List).
Re:Here we go again (Score:5, Interesting)
I think J2EE "fanboys" are either too lazy to learn something new, too philosophically rigid to allow for the possibility that there are other ways to accomplish the task at hand or don't, or they're worried that RoR becoming popular would invalidate their 5 years of J2EE experience.
I know people that probably fit this bill in some manner. I would hope for their sake and the sake of their organizations, however, that they'd be willing to pragmatically look at the problem being presented and make a decision based on what's best for the organization, be it Java or Ruby. At the end of the day I believe being a good technologist and a good communicator, being eager to learn and willing to try new things is more valuable than just being a Java wonk. Flexibility is a virtue. I imagine most Java developers are more flexible than you give them credit for. Although I know there are exceptions.
Re:You are all wrong (Score:1, Interesting)
Well, I think it's pretty obvious that we're talking about the Ruby on Rails implementation of Ruby and Sun's implementation of Java here, so in effect we are comparing implementations, not the languages themselves. That's just the way programmers talk about stuff and most are easily able to make that connection without requiring explanation.
What you said is absolutely correct and I totally agree, but it's not really applicable in this situation.
looks interesting, but does it have to be ruby? (Score:5, Interesting)
Otherwise, I think I'd just rather stick with Python... It seems to have a bigger and more mature standard library, and I can find more web hosts to support it... I'm not trying to start a language war, I'm just looking for the practical solutions...
Re:Ruby is a toy (Score:3, Interesting)
Does my custom solution do absolutely everything that the Massive All-Purpose Java solution does? No, and that's half the point. I can still add what I need faster than you'd believe.
Normally I'm all about using libraries, but there is a cost to them as well (bending your app to the library's assumptions), and these languages make some things so easy it's not worth it anymore.
Re:Security (Score:3, Interesting)
Re:Mojavi (Score:3, Interesting)
Re:Hibernate too hyped (Score:2, Interesting)
>Hibernate seems to be the most hyped technology for
>webapps on java right now.
I use Hibernate for databinding in production systems with thousands of users. I don't think of anything as "hype" when it works. Hibernate is very good at what it does, although it is a little tricky to learn how to use it effectively.
As to the comparison of configuration lines, you have a huge amount of power in Java config, and the tradeoff for that, of course, is a little complexity.
Re:Line counts, method counts.. all lies. (Score:5, Interesting)
Good point about the getter/setter methods. To which I reply: You know they can be generated for you if you use a modern language like Ruby.
class Foo
attr_accessor
end
Now the class Foo has accessor methods (getter and setter) for the instance vars bar, baz and foo.
A total of six methods were created from that one line of code. No need for a 'modern Java IDE' - vi or emacs work fine. You want read-only access? Use attr_reader then only the getter methods will be created.
This is probably why the method count for Ruby in the article was significantly less than for the Java version.
Re:Mojavi (Score:3, Interesting)
PHP is now very tired after that race. Please let it lie down and rest.
Re:any comparison like this... (Score:1, Interesting)
Re:Faster? (Score:3, Interesting)
There are multiple sources for Ruby modules, as I'm sure you already know. So far they've worked out quite well for me.
I agree that RubyGems is quite brain-damaged.
What Hibernate is not (Score:2, Interesting)
It ain't fast. It's not dog slow, but you've got to pay the piper somewhere. If you cache out the wazoo you can get some decent performance, but then you pay in memory. (and if you're clustering, in multicast interserver network traffic)
So get over it and use the tool for what it was meant to be used.
I use both J2EE and Ruby on Rails (Score:5, Interesting)
That said, I have been working through the fantastic second edition of "Programming Ruby" and I have been using Ruby on Rails. Another great technology for use in my consulting business!
While I understand that it is good for developers to share their experiences as per what works for them and what does not, I think that these J2EE vs. RoR discussions are starting to loose value based on the time spent on them.
Now, to get up to speed on J2EE probably takes several months of dedicated study and lots of experience. Ruby and specifically Ruby on Rails might take a half dozen evenings of study instead of watching TV. If you are a J2EE developer the cost of trying RoR is low. The cost of trying J2EE is much higher.
The choice of platform does not have the impact that design choices make on the success of projects. This is obvious, but: do some up front analysis and then try to use the best tool for a job.
BTW, I have a few open source projects in both Java and Ruby (shameless plug
Sure. (Score:5, Interesting)
Rails sucks because David thinks security is your problem, and leaves in functionality that can easily be misused to create a security problem if you haven't read the rails code thoroughly to understand what its doing underneath. Convenience trumps security in rails development.
Rails sucks because its development is incredibly mysql centric, and doing anything beyond the basics with real databases will result in tons of bugs, and then you are told "try again in a few weeks when there's a new version, it should be fixed by then". Then the new version has different bugs instead. Continue this cycle until you decide to use mysql or stop using rails.
That's all I've got, any other problems I've seen are personal preference issues, or things that can easily be fixed as rails matures.
Re:Security (Score:2, Interesting)
Scaffold is vulnerable, input any data like
and when you see the data it will happily execute that code.
The bug tracking system they use is also full of XSS holes. Browse their database and you risk giving your login/password to anybody.
Even on the tutorials, they teach people to write XSS vulnerable software. From the first tutorial [onlamp.com]:
The user only has to input
for the title, and presto, he can get all other user's cookies
All the other tutorials have the same vulnerability.
The developers don't care about these. Some people even activelly oppose fixing them. I can only imagine what else is in there. I wouldn't touch ruby on rails with a 10 foot pole for anything where security mattered.
Re:looks interesting, but does it have to be ruby? (Score:5, Interesting)
Oh, of course you are. Might as well just admit it.
As far as Ruby vs. Python features go:
1) code blocks. Ruby lets you pass code blocks around. Sounds pretty dull, eh? But in fact it's what makes it possible to create Domain Specific Languages in Ruby quite easily without needing to create a special parser. In many ways Rails can be thought of as a domain specific language built on Ruby.
2) classes are always open in Ruby(including the Class class). By 'open' I mean you can always add new methods to a class (or even a particular object). Another feature that makes it easy to create DSLs
3) continuations. (Not that Rails makes use of them, but some other Ruby-based web programming frameworks do)
4) Ruby has true lambdas. AFAIK Python's lambdas are pretty limited (limited to one expression?)
Also, can you embed Python in HTML? (seems that the whitespace issue would cause a lot of problems with doing that)
I'm just looking for the practical solutions...
Give RoR a try. You might just find that it'll do everything you need it to do now without needing to wait around for a Python-based clone. What could be more practical?
Re:Here we go again (Score:5, Interesting)
People who are "fanboys" may just be so invested in [something] that to achieve the same depth of _tested_ knowledge in [something else] would take five years. They may in fact be looking at things like Ruby, but they aren't planning on switching their production development to it until both they and it are seasoned because it would be insane to do so. It's not just THEIR level of comfort that is in question, it is the organizations ability to accept it.
Before someone slams on corporate culture limiting your godlike creative powers, it's actually pretty reasonable. A business is a machine. You want to get some return on the machine before you rip the engine out and retool it--and that timeframe is generally ~5 years. Think of it like buying a car. YOU may be able to afford to replace yours every year or maybe you're a grease monkey who does a frame-off rebuild every spring just for kicks, but the vast majority don't want to go through the hassle and expense on an annual basis.
So, Ruby has now reached the point where it is a serious contender. Expect it to start replacing J2EE somewhere between 2008-2010.
Re:Part of the Reason (Score:3, Interesting)
I think part of this also is what you pointed out, people who went into CS because that's where the money was. For my part I studied English in college. I wrote a lot. I read a large chunk of the classics of post-modern, modern and earlier literature. And then somewhere halfway through college I fell in love with computing. So I bought "Teach Yourself C on the Macintosh" (I think because it was the book in the store that came with a compiler, whereas the Pascal book didn't).
Then when I graduated from college, being a former landscaper, I applied for a couple different jobs. One was as a landscaper. One was for $10 an hour doing HTML, JavaScript, CSS, Photoshop, etc. I got the web job first, so I became a programmer. I didn't seek it out, but rather fell into it and enjoy it enough to keep learning new things.
I think you're right that there is a distinct difference in mindset there. I wasn't looking for a career. I was looking for a job I enjoyed. And all the same I won't fight against new technologies to cling to my newfound career. I could easily be happy doing landscaping if for some reason all the world needs is Java experts. But if they need generalists who love what they do, then I won't be planting trees again for a while.
That's how I look at it.
Zope 3 (Score:4, Interesting)
Re:Ruby on rails performance (Score:5, Interesting)
-----
A few problems with your testing that I could see:
"So, for the sake of total specificity, the following numbers were generated on a 1.5GhZ Mac OSX (10.3.7) PowerBook with a 4200rpm hard drive and 1GB of RAM."
The Java Virtual Machine running on Macs has always been questionable. Its not Sun's implementation and has not been as heavily updated by Apple. First I would start by running your tests on a Windows or Linux box using the Sun JRE 1.5.
"The Java app is running on Jakarta Tomcat v 5.0.28, while the Rails app is running in Lighttp with FastCGI. The setups are standard for each application stack."
As mentioned by a prior poster, Tomcat is only a reference implementation. Its not built for speed. The Ruby setup you used, on the other hand, is. This alone is a major oversight in your testing.
"Number of Methods:
Rails: 126
Java: 549"
Having to write 4 times as many methods is a clear indicator that you are using the wrong framworks to get the job done. There are hundreds of frameworks for building web applications between the languages. Spring with Hibernate must not be the right mix.
"Configuration Lines
Rails: 113
Java: 1161"
I am guessing you used Xerces for parsing on the Java side. This is bad since Xerces is not a very quick parser and there are plenty of Java XML parsers that are much better suited when speed is concerned. Look at using XPP or Lightning instead. With JAXP (if Hibernate and Spring support it) you will not have to change code to use these in place of Xerces. Also, any time you are comparing a XML parsed document versus and non-XML parsed document the latter will always win. Try using frameworks that do not depend on XML configuration files.
True language performance comparisons should never be done with web applications. There are simply too many variables. I know this was not your intent (doing language performance comparisons), but that is how your article is being viewed by others. People are always itching for a battle between the languages.
Different languages are suited for different tasks better than others. For example, I once had to translate a Perl application to Java for my work. Due to what that Perl code was doing, the finished Java application was several times larger and slower. Perl was better due to the task at hand.
Re:You are all wrong (Score:1, Interesting)
Show me the code (Score:3, Interesting)
Re:looks interesting, but does it have to be ruby? (Score:5, Interesting)
def func():
def my_code_block():
print "Hello, World!"
return my_code_block;
f = func();
f();
Of course. You're basically passing around a function reference. That's not what I'm talking about.
What Python doesn't have is nice, clean, anonymous code blocks
That's what I'm talking about. In Python you can't do something like this:my_while looks like a natural extension of the language. I'm sure you could duplicate this function in Python, but it wouldn't look like a natural part of the language.
Here's why Ruby is not an option (Score:3, Interesting)
Unicode is expected in v2.0, but nobody knows when it will come out.
Plus, the IDE doesn't support code completion, and having worked with code completion for years now I'm now much less productive without it.
Re:any comparison like this... (Score:2, Interesting)
2. Yes, but J2EE is an overblown, overladen framework to begin with. When people need queueing and remoting technologies with ROR, it will be added. In fact, the remoting technology -- at least in part -- is already there through DRb (if you haven't looked at it, you should) and Florian Groß's breakpoints code. I would strongly disagree with your assertion that the J2EE components for these are "comprehensive" and especially "unified."
3. Again, you *can* do field name mapping, but it's a bit more work to do so. There's no reason you can't create aliases, e.g.:
def deg_f=(fahrenheit)
write_attribute("celsius", (fahrenheit - 32) * 9 / 5.0))
end
def deg_f
(read_attribute("celsius") * 5 / 9.0) + 32
end
See http://ar.rubyonrails.com/classes/ActiveRecord/Ba
Field name mapping is easy; not as easy as simply following the Rails model, but it's *easy*. SOAP is a bit harder, and other stuff maybe a bit harder still. It's all still easier than trying to pick up all of J2EE.
-austin
Code Completion (Score:3, Interesting)
However, most developers agree they are more productive in languages like Python, Ruby or OCaml than they are in languages that do have auto-complete environments (e.g., C++, Java, C#, etc...).
This shouldn't be taken as a "We don't need no stinkin' code completion" comment. It's just an observation that code completion would be icing on the cake, but the cake is allready there, tasty and full of chocolate.
If you want to try ruby with code completion, check out FreeRIDE [rubyforge.org]. It is not done yet, but it'll show you the direction things are going.
Re:I was unclear about YARV. Let me clarify (Score:3, Interesting)
To which I'd like to add, "et cetera [reference.com]: et = and, cetera = the rest" . There is no work "eck" in the Latin language, and the phrase "Eck cetera" is nonsense. And you sound stupid if you say it. And, while I'm on the subject, there are two "s"s in the word asterisk. It's not an asterick, even if you verb it.
The fact that bringing ignorance to the attention of the general populace is considered worse than being ignorant itself is a sure sign that we've reached a period of pure intellectual unenlightenment - the second dark ages hath begun. Well, Paradox, let me be the first to stand behind you in solidarity in the battle against stupidity and deliberate ignorance.
Re:You are all wrong (Score:2, Interesting)
You are incorrect.
It has become quite difficult to ignore the reality that for advanced GUI coding, C++ has established itself as one of the few languages that truly scales to operational use. From an operational standpoint -- meaning, roughly, that the output is actually something you want to run, only the following toolkits have responsive, shell-integrating output:
1) MFC (C++)
2) Qt (C++)
3) WxWindows (C++, and something I've only recently been convinced of by NessusWx. I haven't seen anything fairly mature out of Perl/Python Wx bindings yet. There's a reason everyone's waiting for Open Source Qt4.)
4) Delphi (Very noticably not C++, not exactly Pascal either.)
5) VB (Also not C++, but has an entirely different set of scalability problems)
That's pretty much it. However Swing is to code for, it's more painful to deploy and just a beast to use. (It's 2005 and, like PKI, Java on the Desktop is an expensive joke that's no longer funny.) I keep wanting to see good things from SWT, but however the system looks it's just not very responsive -- either in boot time or in actual use.
The only thing I actually vacillate on is GTK in C. Scite and GAIM provide acceptable, even very good output. It sure doesn't look very nice to code for though.
I reserve judgement on C#'s Windows.Forms for now.
Ultimately, surveying the field, C++ is really doing something right, and it's time people stop repeating the Alice-In-Wonderland myth that you wouldn't want to use it for GUI development. GUI's are one of the big reasons *to* use C++...everything else can hide its performance problems on a remote server, or by the lack of need for interactivity.
Incidentally, don't discount the problems introduced by interpreters. You know why Flash still fails as a GUI hosting platform, despite appearing to be a perfect choice? Event loop speed. Flash updates events only a couple times a second, meaning you're sitting there, waiting hundreds of milliseconds for your change to get noticed. Java has had similar problems.
Of course it requires less coding... (Score:1, Interesting)
The Ruby folk go to extremes sometimes to get developers' attention: here they're presenting Ruby on Rails as something as wonderful and new,whereas every language has such code generators: Perl has Mason, MayPole and many others that do everything RoR does but without the insane premise that "everything is an object" (which Ruby is based).
Ruby is one man's honest effort to objectify Perl. A good effort, I might add, but because it's derived from Perl and has such a small user base, Ruby will remain a niche language.
Re:You are all wrong (Score:3, Interesting)
"Normal Spring/Hibernate" (Score:3, Interesting)
My first issue with this is that he uses spring and hibernate and then compares speed. WTF is this about? You use an OR mapping tool that is fairly robust and you then talk about speed? Why didn't he just code all the SQL by hand and forget Hibernate. On a LOT of applications this would perform much better. Heck he could even rip Spring out and again do what he needs by hand.
How much would that have reduced the size?
Now for my next question. How did both applications scale? Where both speeds acceptable at the required load/user level? Heck if you are building a system that you want to maintain, and potentually switch out databases, then Hibernate ROCKS. Yes there is some overhead, but for 99% of the applications on todays hardware this will not be an issue.
Re:Here we go again (Score:4, Interesting)
One reason for this is because their IT departments discovered a few years ago that they have accumulated all sorts of crufty code written against multiple languages and platforms, and had no way to manage it because all the contractors who wrote it had taken the money and run. Seeing shrinking IT budgets, and new platforms (like ROR) coming out every year, they decided to make their lives easier by standardizing on the most best-of-breed (read: most resumes available) platforms. This would allow their IT folks to only have to learn one set of technologies to deploy and manage applications internally.
IT managers like standard platforms, because they are sold on the idea that they can develop "web services" which can let apps "transparently share data" and allow for "collaborative whatchamacatchie". Most often, the reality is that these organizations still have a tremendous amount of data scattered across N databases and M organizations, and no magic dev platform is going to solve that without effort.
I regard most of the J2EE architecture as over-engineered and overkill on most projects I've done. I prefer to use it stripped-down as I can get away with. Heck, I could probably embed a Jython interpreter in a servlet and use it on a project without anyone noticing. But for large organizations, the trend is toward less diversity.