Forgot your password?
typodupeerror
Programming IT Technology

Ruby On Rails Showdown with Java Spring/Hibernate 555

Posted by Hemos
from the battle-of-the-overhead dept.
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?"
This discussion has been archived. No new comments can be posted.

Ruby On Rails Showdown with Java Spring/Hibernate

Comments Filter:
  • Re:Faster? (Score:5, Insightful)

    by Anonymous Coward on Monday April 04, 2005 @11:34AM (#12134138)
    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.
  • Here we go again (Score:1, Insightful)

    by pj-allmod (822913) on Monday April 04, 2005 @11:35AM (#12134143)
    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.
  • Re:Faster? (Score:5, Insightful)

    by sporty (27564) on Monday April 04, 2005 @11:35AM (#12134151) Homepage
    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.
  • by fedork (186985) <fedor.apache@org> on Monday April 04, 2005 @11:36AM (#12134156)
    ...

    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 /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
  • by Pac (9516) <paulo...candido@@@gmail...com> on Monday April 04, 2005 @11:38AM (#12134179)
    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.
  • Re:Faster? (Score:5, Insightful)

    by rbarreira (836272) on Monday April 04, 2005 @11:38AM (#12134182) Homepage
    Yeah, an optimized compiler isn't the same thing as an optimizing compiler...
  • by Pants75 (708191) on Monday April 04, 2005 @11:40AM (#12134202)
    Code base size and speed aside.

    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)

    by Anonymous Coward on Monday April 04, 2005 @11:41AM (#12134205)
    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.
  • by OwnedByTwoCats (124103) on Monday April 04, 2005 @11:46AM (#12134265)
    I can't read TFA; slashdot effect?

    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)

    by Tobias Luetke (707936) on Monday April 04, 2005 @11:51AM (#12134310)

    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

  • by LnxAddct (679316) <sgk25@drexel.edu> on Monday April 04, 2005 @11:53AM (#12134325)
    In addition to that, how well does the ruby implementation scale? My understanding is that a good J2EE implementation is capable of scaling to thousands of clients (one article I read claimed a 250,000 client load), the ruby implementation might start crawling after as little as 50 clients. Turning up a page 125ms faster is more or less meaningless when you can't reach most of your potential customers, and more importantly, after a few start visiting it gets slower and slower. So I'm curious to see what kind of extensive laod testing he did for both implementations. Other important things to consider are how complex his needs are compared to an enterprise and how extensible both implementations are. How exactly did this Joe Schmoe get on the front page of slashdot?
    Regards,
    Steve
  • by lbmouse (473316) on Monday April 04, 2005 @11:53AM (#12134329) Homepage
    Add one more to your list: General Acceptance.

    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.
  • by Paradox (13555) on Monday April 04, 2005 @11:54AM (#12134340) Homepage Journal
    Justin is a respected and skilled Java developer who's got a Developer's Notebook for Spring set to hit the shelves any day now.

    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.
  • by ahmetaa (519568) on Monday April 04, 2005 @11:56AM (#12134362)
    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.
  • by ajs (35943) <ajs@nOsPam.ajs.com> on Monday April 04, 2005 @11:56AM (#12134363) Homepage Journal
    "A laguage, in of itself, cannot be measured by speed."

    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.
  • by alex789 (873201) on Monday April 04, 2005 @11:58AM (#12134382) Homepage

    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.

  • by Anonymous Coward on Monday April 04, 2005 @12:01PM (#12134417)
    Why do most of the article submitters have to end their summaries with a moronic or otherwise obvious or thought un-provoking question?

    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?"

  • by Espectr0 (577637) on Monday April 04, 2005 @12:01PM (#12134419) Journal
    Hibernate seems to be the most hyped technology for webapps on java right now. I evaluated it to use it on my thesis.

    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 .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)

    Disclaimer: i don't have any relationship with sqlmaps, i am just a happy user.
  • Re:Wait..... (Score:4, Insightful)

    by markv242 (622209) on Monday April 04, 2005 @12:05PM (#12134453)
    I think the reason why I don't admin a huge corporate dynamic website is about to be pointed out though.....
    Well, if you insist...

    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.

  • by Anonymous Coward on Monday April 04, 2005 @12:07PM (#12134468)
    Let me know more about those mysterious purely functional languages that can't be optimized.

    Oh, and read Boquist 99, I think it covers producing optimized code for lazy functional languages.
  • Second Time Around (Score:2, Insightful)

    by Doc Ruby (173196) on Monday April 04, 2005 @12:07PM (#12134473) Homepage Journal
    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.
  • by Anonymous Coward on Monday April 04, 2005 @12:08PM (#12134483)
    Apparently you didn't evaluate it all that closely, or you'd have noticed that you don't have to autogenerate schema from the objects. You have full control to manually write the db-to-object mappings.
  • by swimmar132 (302744) <(ten.rekcupknip) (ta) (eoj)> on Monday April 04, 2005 @12:09PM (#12134491) Homepage
    With fastcgi and a decently tuned server, I've heard people getting 1000 req's per second. And lighttpd doesn't take up much memory. And you can always add more applications servers if that's not fast enough.
  • Re:Security (Score:5, Insightful)

    by Xugumad (39311) on Monday April 04, 2005 @12:10PM (#12134495)
    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?
  • by ewg (158266) on Monday April 04, 2005 @12:10PM (#12134497)

    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.

  • by skubeedooo (826094) on Monday April 04, 2005 @12:21PM (#12134597)
    However, it [sic] you are doing low-level real-time I/O where constants do matter, then C/ASM is probably the way to go.

    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.

  • by dDrum (727937) on Monday April 04, 2005 @12:22PM (#12134609)
    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.
  • by nitehorse (58425) <clee@c133.org> on Monday April 04, 2005 @12:25PM (#12134634)
    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.
  • by fritter (27792) on Monday April 04, 2005 @12:33PM (#12134716)
    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?
  • Wrong attitude. (Score:2, Insightful)

    by Some Random Username (873177) on Monday April 04, 2005 @12:35PM (#12134745) Journal
    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.
  • by swimmar132 (302744) <(ten.rekcupknip) (ta) (eoj)> on Monday April 04, 2005 @12:43PM (#12134823) Homepage
    Any developer who can't pick up Ruby in a couple days is a developer who you should not hire.

    It's not like C++ (which, in my experience, takes a LOT of training in order to become proficient).
  • by reaper (10065) on Monday April 04, 2005 @12:46PM (#12134859) Homepage Journal

    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)

    by Safety Cap (253500) on Monday April 04, 2005 @12:49PM (#12134886) Homepage Journal
    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.
  • by northcat (827059) on Monday April 04, 2005 @12:55PM (#12134938) Journal
    Did you even read the summary? We are talking about two implementations of two applications, not the very syntax of the languages themselves. Yeah, we all know that a language by itself can't be fast or slow blah blah blah. Whenever we're having a practical discussion about a "language", we're talking about the syntax *and* the general qualities of its implementations - in this case there is only one significat implementation of each. This one summary itself would take the entire slashdot frontpage if we had to mention every particular detail like this. BTW, when people say "java is slow" they mean the most significant implementation of java is slow. They're just trying to be concise, practical and to the point.
  • Out of the box (Score:3, Insightful)

    by fishdan (569872) * on Monday April 04, 2005 @12:58PM (#12134964) Homepage Journal
    Alot of what has happened to Java is feature creep and bloat. I think that Ruby is likely to suffer the same fate at some point. Lean and Mean will always be faster than Big and Powerful. Comparing Ruby and Java is like comparing MySQL and Oracle. Of course MySQL is faster than Oracle for many things. Just as when Oracle was the upstart and THEY were faster than all the Old guys on the block.

    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.

  • by CatGrep (707480) on Monday April 04, 2005 @01:00PM (#12134985)
    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?

    (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.
  • by yasth (203461) on Monday April 04, 2005 @01:12PM (#12135084) Homepage Journal
    A lookup is still constant(ish) time. Would I use python to implement an OS? Probably not, but it will scale pretty much the same as anything else. And CPU speed is often in surplus.

    C++ is not even a tool option for a wide variety of embedded architectures. Existence is a very big benefit.
  • by ux500 (204135) on Monday April 04, 2005 @01:25PM (#12135263)

    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)

    by snorklewacker (836663) on Monday April 04, 2005 @01:34PM (#12135362)
    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.
  • by ReelOddeeo (115880) on Monday April 04, 2005 @01:38PM (#12135404)
    C has NO benefits over C++

    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?
  • by javaxman (705658) on Monday April 04, 2005 @02:10PM (#12135776) Journal
    I think that the Java version is just as capable, and could be just as performant, as the Rails app. To me, the eye-opening revelation isn't "Rails is faster than Java/Spring/Hibernate". It's "Rails can be very fast". I think that there is a lot to be said for Rails, and it deserves much of the press it is getting. However, I don't think its a Java-killer. I think there are plenty of applications, and development teams, that are better suited to Java and its immense universe of available support libraries. I certainly am not going to stop developing in and learning about Java just because I've discovered Rails.

    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)

    by Anonymous Coward on Monday April 04, 2005 @02:16PM (#12135840)
    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.
  • by Listen Up (107011) on Monday April 04, 2005 @02:20PM (#12135881)
    The second post of yours is much more intelligent and much less ignorant and arrogant than your first post. I rolled my eyes when I read your first post.

    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.
  • by dubl-u (51156) * <2523987012@pota . t o> on Monday April 04, 2005 @02:47PM (#12136157)
    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.

    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.
  • by hey! (33014) on Monday April 04, 2005 @03:10PM (#12136401) Homepage Journal
    I've looked at Rails, and I'm very impressed.


    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.

  • by Some Random Username (873177) on Monday April 04, 2005 @03:46PM (#12136776) Journal
    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.

    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.rail s/749/match=sql+injection [gmane.org]
    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.
  • by Listen Up (107011) on Monday April 04, 2005 @04:43PM (#12137495)
    Whatever you wish to say about 'real corporations' is fine with me. There are many different kinds of working environments in the world. I have no turf to protect and I am neither ignorant nor arrogant.

    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.
  • by ajs (35943) <ajs@nOsPam.ajs.com> on Monday April 04, 2005 @06:04PM (#12138409) Homepage Journal
    "What a bunch of crap."

    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 ... actually, I'm not clear what it is that you're trying to accomplish.

    "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.
  • by Anonymous Coward on Monday April 04, 2005 @08:12PM (#12139483)
    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.

A bug in the code is worth two in the documentation.

Working...