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:
  • Faster? (Score:5, Funny)

    by Cruithne (658153) on Monday April 04, 2005 @11:31AM (#12134109)
    ...Ruby is getting a new optimized bytecode compiler for its upcoming 2.0 release. Will Ruby on Rails become even faster as a result?

    I would assume so, doesn't optimized usually mean faster?
    • 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.
    • Obligatory (Score:5, Funny)

      by Anonymous Coward on Monday April 04, 2005 @11:34AM (#12134142)

      doesn't optimized usually mean faster?

      I'd give you an answer, but I haven't been able to fully test out my optimized Gentoo box yet -- it's still compiling.

    • 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.
      • 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...
      • Re:Faster? (Score:5, Informative)

        by ajs (35943) <ajs AT ajs DOT com> on Monday April 04, 2005 @11:44AM (#12134241) Homepage Journal
        When we say "optimized bytecode compiler" these days, we generally mean that it does JIT. I know, I know, it's bad use of the terminology, but generally that's what people mean.

        Ruby has one other massive advantage over Java on the medium-term horizon: Parrot. The Ruby-on-Parrot effort is progressing nicely, and when that is complete, Ponie [poniecode.org] will give Ruby transparent access to all of CPAN (thought yet another JITted bytecode system) even for those who don't like or can't use Perl.

        At that point, Ruby becomes (IMHO) the most attractive HLL in existance (until Perl 6 lands... IF Perl 6 lands...)
        • Re:Faster? (Score:4, Funny)

          by hawk (1151) <hawk@eyry.org> on Monday April 04, 2005 @03:49PM (#12136804) Journal

          >Ruby has one other massive advantage over Java on the medium-term horizon: Parrot.

          You're just repeating what they told you, aren't you?

          :)

          hawk

    • 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.
  • Fifteen to thirty percent faster, and still crushed under the load of Slashdot.

  • 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 Weaselmancer (533834) on Monday April 04, 2005 @11:49AM (#12134292)

      Language is merely description, implementation is what you can benchmark.

      And I also have to say, what we've got here is the single most intelligent AC post in the entire history of Slashdot.

    • 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 jfengel (409917) on Monday April 04, 2005 @11:53AM (#12134330) Homepage Journal
      This is all true, but as software developers we tend to use the word "language" loosely to mean, "The syntax, the compiler, the libraries, and the execution environment." So while a language can't be inherently faster than another, some languages have highly efficient, readily available implementations, and others don't.

      That's a matter only of constant speedup, assuming that the implementation is competent, and therefore theoretically swamped by the complexity of the algorithm. But if you've implemented the same algorithm using both systems, a constant speedup of 10 is an order-of-magnitude speed improvement. Even with the really, really fast computers we use today that makes a difference to a lot of applications. (And I've used plenty of languages where could get a 10x improvement by switching to a better language.)

      In this case there isn't even a single Java environment; there are numerous JVMs out there and I hope they tested several of them before writing the article. (I doubt it, but that's a whole different story.) You're probably not going to get a 10x difference, but 2x wouldn't be uncommon for certain applications.

      So you're using the terminology correctly and everybody else is using it wrong. They should talk about the "Java system" or "Java environment" rather than Java language. But I think nearly everybody reading the article knew what was meant.
      • by iwadasn (742362) on Monday April 04, 2005 @02:11PM (#12135786)
        I would like to point out that the non GUI elements of the OS X JVM are about the worst around in terms of performance. It seems very clear that apple (first and foremost) wanted a JVM that worked and had native windowing, and didn't really worry about performance. There isn't even a -server VM in OS X, and using -server for server applications makes a HUGE difference in performance. I think running it on a modern Linux VM (1.4.x or 1.5.0) using -server would have almost doubled the performance. I am also an OS X user, but I've timed things running on OS X, and java has always been slow for the hardware available.

        It is possible that 10.4 will finally change this and really make OS X a first class java citizen, we'll see. Hopefully the better compilation from gcc 4 and 64 bit everything will help substantially. Good vectorization, and an auto-vectorizing bytecode compilier would go a long way towards fixing this embarassing little weakness. Also, including a -server VM wouldn't hurt either, if Apple wants their computers to be taken seriously in the Datacenter (Xserves).

    • by ajs (35943) <ajs AT ajs DOT 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.
      • Re:You are all wrong (Score:3, Interesting)

        by kubalaa (47998)
        FYI: the higher level a language is, the *more* possible it is to optimize in general (though the optimizations may be difficult). It is languages like C that are "impossible to optimize", since they way overspecify, for example, the order-of-execution, and force optimizers to bend over backwards preserving semantics that the programmer doesn't even care about.
    • by northcat (827059)
      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 ha
  • Article Text (Score:5, Informative)

    by Anonymous Coward on Monday April 04, 2005 @11:41AM (#12134211)
    Article text in full, copied directly from Justin's blog:

    So, a few weeks ago I made an offhanded post here about my new-found love for Rails. I'd been skipping off the surface of Ruby for a while, trying to decide if it, or Python, or Groovy, or something else, ought to fill out the empty slot in my tool belt. (I'll save the "why LISP isn't on this list" post for another time.) Rails seemed like an excellent way to put Ruby through a workout, and I had the right sized project to try it out with.

    The project itself is not open-source; the client is now and shall remain anonymous. But they are paying me my going rate to do this work, which makes it a commercial Rails project, and it will in the future be installed into some rather large organizations. I can't really say much about what the application's domain is, but I can lay out the general principles of the app.

    The application must support multiple users, in the order of 10-100 concurrently. The load isn't particularly high, but the application will be treated like a desktop app (more specifically, a spreadsheet replacement) so it has to be responsive. The application is for managing pieces of a large machine process. There are lots of types of components to be managed, and the relationships between them can be quite complicated. There are no one-to-one relationships in the model, but plenty of one-to-many and many-to-many. In addition to managing the components, the application has to allow for the addition of entirely new categories of components as well as a variety of customizable fields. Finally, the authorization rules call for a breadth of user roles with a complex mapping of permissions to those roles.

    I've finally gotten around to running the profiling numbers and doing some comparison between the two systems. I won't spoil the suspense by listing my conclusions up front -- you'll have to scroll through the rest of the post to see them. But, first, let me set the stage: the original application is based on the Java/JSTL/Spring/Hibernate/MySQL stack. I used ACEGI for the security, SpringMVC for the web controller, and was using Hibernate 2.x for the O/RM. To increase performance, I was using the default output caching from SpringMVC and data caching in Hibernate. The re-implementation is in Rails on top of MySQL. The authorization is done through a custom observer and a custom authorization class, which uses a declarative rules file for permission mapping. For performance, I'm using a combination of page caching, action caching, and cache sweepers (observers whose job it is to expire cached pages).

    Now, for the comparisons:

    Time to Implement
    I made a comment about this in the previous posts on the topic, and that comment has been quoted widely out in the wide blogosphere as a classic example of Rails hype. So, let me make it plain: any time you re-write an application, it will go almost infinitely faster because you already have a firm grasp on the problem domain. Such was the case for me in my re-write; we'd spent so much time on the domain model and the database schema that the second time through the application, everything already made perfect sense to me. Any comparison of how long it took to implement one or the other is bogus, since the only fair comparison would be to implement two roughly functionally equivalent projects in the two different stacks and measure the competitive results. Since I have not done that, making statements about how it only took 5 days to re-implement the site are almost meaningless. What I can say is that I had more fun implementing it the second time, but that's just personal preference.

    Lines of Code
    This one is a lot more interesting. Folks will tell you all the time that there is a running debate about the meaningfulness of LOC comparisons. They're right; there is a running debate. I just think it's moot. For my money, the fewer lines of code I have to write to get a piece of functionality, *as long as those lines are clear in meaning*
  • Mirror (Score:5, Informative)

    by blackmonday (607916) on Monday April 04, 2005 @11:48AM (#12134282) Homepage
    Mirror Here [mirrordot.org].

  • First Post! (Score:5, Funny)

    by lexbaby (88257) on Monday April 04, 2005 @11:50AM (#12134305) Homepage
    First post!

    --
    Posted Via JFPB - Java First Post Bot
  • 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

    • Re:Application (Score:4, Informative)

      by Politburo (640618) on Monday April 04, 2005 @12:20PM (#12134585)
      Whats interesting is the development speed and thats what the comparison between the java and the rails version highlighted well.

      No, the comparison did not highlight this. The development speed was not comparable because when the app was written in Ruby, it was not the first time the app was written. As such, many development problems had already been resolved. This is noted by the author in the post.
    • 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.

    • by Da Fokka (94074) on Monday April 04, 2005 @01:55PM (#12135607) Homepage
      There is nothing easier to scale then webapps in the world.
      Yes there is. Writing shakespeare. Just add more monkeys and more typewriters.
  • Mojavi (Score:5, Informative)

    by joelhayhurst (655022) on Monday April 04, 2005 @11:57AM (#12134379)

    Slightly off topic, but thought some might be interested.

    There is a pretty cool and full featured MVC framework for PHP called Mojavi [mojavi.org]. If you like PHP and think Ruby on Rails or any other MVC framework is what you're into, you might want to check it out.

    • Re:Mojavi (Score:3, Interesting)

      by MAdMaxOr (834679)
      I tried Mojavi, and I liked it. However, it's not nearly as compelling as RoR, mostly because it's missing the *magic*. Mojavi is condensed best practices for PHP, and RoR is new, and borderline voodoo.
    • Re:Mojavi (Score:3, Interesting)

      by CatGrep (707480)
      RoR has given PHP a run for it's money.

      PHP is now very tired after that race. Please let it lie down and rest.
  • 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.
    • by Anonymous Coward
      I use both iBatis sqlmaps and Hibernate in my projects. iBatis is great for interfacing with our legacy database. Porting old SQL queries from our legacy software to Java middleware is a snap. It is excellent software no doubt, but it doesn't have the advanced ORM features that Hibernate has. Though it is much easier to use.

      We are using Hibernate in our new software. Hibernate has excellent SQL generation. Since it has its own abstraction from SQL, it can do things to optimize your queries in ways yo
    • iBATIS SqlMaps [ibatis.com] is my persistance *assistance* technology of choice, and have been for two years.

      Notice *assistance* - it is not *meant* to compete with ORM solutions like Hibernate, which is why I use it. Ted Neward expresses it best: "Object-relational mapping is the Vietnam of Computer Science" [neward.net]

      My take? Relational databases are procedural in nature, not object-oriented. Get over it, and stop trying to pretened otherwise! iBATIS SqlMaps makes writing relational database "method calls" very easy, and st

    • by ux500 (204135)

      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 Hibern

    • by dubl-u (51156) * <[2523987012] [at] [pota.to]> 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.
  • TFA (Score:3, Informative)

    by daddyam (873272) on Monday April 04, 2005 @12:09PM (#12134488)
    Some Numbers at Last

    So, a few weeks ago I made an offhanded post here about my new-found love for Rails. I'd been skipping off the surface of Ruby for a while, trying to decide if it, or Python, or Groovy, or something else, ought to fill out the empty slot in my tool belt. (I'll save the "why LISP isn't on this list" post for another time.) Rails seemed like an excellent way to put Ruby through a workout, and I had the right sized project to try it out with.

    The project itself is not open-source; the client is now and shall remain anonymous. But they are paying me my going rate to do this work, which makes it a commercial Rails project, and it will in the future be installed into some rather large organizations. I can't really say much about what the application's domain is, but I can lay out the general principles of the app.

    The application must support multiple users, in the order of 10-100 concurrently. The load isn't particularly high, but the application will be treated like a desktop app (more specifically, a spreadsheet replacement) so it has to be responsive. The application is for managing pieces of a large machine process. There are lots of types of components to be managed, and the relationships between them can be quite complicated. There are no one-to-one relationships in the model, but plenty of one-to-many and many-to-many. In addition to managing the components, the application has to allow for the addition of entirely new categories of components as well as a variety of customizable fields. Finally, the authorization rules call for a breadth of user roles with a complex mapping of permissions to those roles.

    I've finally gotten around to running the profiling numbers and doing some comparison between the two systems. I won't spoil the suspense by listing my conclusions up front -- you'll have to scroll through the rest of the post to see them. But, first, let me set the stage: the original application is based on the Java/JSTL/Spring/Hibernate/MySQL stack. I used ACEGI for the security, SpringMVC for the web controller, and was using Hibernate 2.x for the O/RM. To increase performance, I was using the default output caching from SpringMVC and data caching in Hibernate. The re-implementation is in Rails on top of MySQL. The authorization is done through a custom observer and a custom authorization class, which uses a declarative rules file for permission mapping. For performance, I'm using a combination of page caching, action caching, and cache sweepers (observers whose job it is to expire cached pages).

    Now, for the comparisons:

    Time to Implement
    I made a comment about this in the previous posts on the topic, and that comment has been quoted widely out in the wide blogosphere as a classic example of Rails hype. So, let me make it plain: any time you re-write an application, it will go almost infinitely faster because you already have a firm grasp on the problem domain. Such was the case for me in my re-write; we'd spent so much time on the domain model and the database schema that the second time through the application, everything already made perfect sense to me. Any comparison of how long it took to implement one or the other is bogus, since the only fair comparison would be to implement two roughly functionally equivalent projects in the two different stacks and measure the competitive results. Since I have not done that, making statements about how it only took 5 days to re-implement the site are almost meaningless. What I can say is that I had more fun implementing it the second time, but that's just personal preference.

    Lines of Code
    This one is a lot more interesting. Folks will tell you all the time that there is a running debate about the meaningfulness of LOC comparisons. They're right; there is a running debate. I just think it's moot. For my money, the fewer lines of code I have to write to get a piece of functionality, *as long as those lines are clear in meaning*, the better off I am. Obfuscated Perl programs don't make the
  • 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.

    • 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).
    • 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++ sh
  • by acomj (20611) on Monday April 04, 2005 @12:13PM (#12134525) Homepage
    This article [theserverside.com] is a good look at RnR(ruby) and Hibernate (java). The author is a java developer and doesn't claim to be a ruby expert, but its interesting analysis about each one.Technical pros and cons of each without a lot of flame bait.
  • by ramone1234 (588375) on Monday April 04, 2005 @12:16PM (#12134549)
    I checked out the video demo at http://media.nextangle.com/rails/rails_setup.mov [nextangle.com] and I have to admit that I'm pretty impressed. This framework eliminates a lot of the tedium that goes into developing web apps... Here's my problem though... Is there any reason it has to be in Ruby? I've heard of python's equivalent 'subway' ( http://subway.python-hosting.com/ [python-hosting.com] ), and I'm wondering if Ruby has some language feature that makes it inherently more suitable than other languages (like python) for this 'rails-style' of development...

    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...
    • by CatGrep (707480) on Monday April 04, 2005 @01:14PM (#12135113)
      I'm not trying to start a language war,

      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?
      • Python's classes support metaprogramming, although it lacks continuations and a non-useless lambda form.

        As far as the OP's question, no, there's nothing at all in Python the language that'd prevent a similar project, although the implementation would be pretty different.
  • 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?
    • Sure. (Score:5, Interesting)

      by Some Random Username (873177) on Monday April 04, 2005 @01:07PM (#12135047) Journal
      Rails sucks because its written in ruby, which is slow (excruciatingly slow for recursion and text processing), and doesn't support OS level threads. The fake threads ruby does have can under uncertain circumstances cause the entire interpreter to block.

      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:Sure. (Score:4, Informative)

        by Paradox (13555) on Monday April 04, 2005 @02:34PM (#12136029) Homepage Journal
        Rails sucks because its written in ruby, which is slow (excruciatingly slow for recursion and text processing), and doesn't support OS level threads. The fake threads ruby does have can under uncertain circumstances cause the entire interpreter to block.
        Get off it. Ruby is not "excruciatingly slow" for anything. It is surely not as fast as some languages, but its speed is obviously good enough, because even without caching the Rails app is faster than the Java app.

        I mean, if caching was the only thing holding Rails afloat, you could draw this conclusion, but even a cursory examination of TFA wills show that's just not true.

        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.
        Making secure actions in Rails is trivially easy. There is even a generator for it. Rails developers are concerned with security, but they've yet to see a scenario where the standard login generators and practices of the rails community require a technical fix.

        Yes, you could bring up Geert's posts point out flaws in Ta-da Lists, but that'd be silly. Every application can have bugs, and Ta-da Lists was ripped wholesale out of Basecamp, reseated, and used mainly as an Ajax demo and advertisement for basecamp.

        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.
        This is no longer true. It was true at one point. Yes, many features go into Edge Rails that are MySQL only, but that's just because the developers tend to know it best. Features don't end up in the mainline unless they're as compatible as people can make them. I cannot deny that some databases are not as well supported as others, though.
        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.
        I think you formed your opinions before the 0.10.0 release. We're closing in on Rails 1.0 now, and things are starting to get really stable.
        • 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.
        • Re:Sure. (Score:4, Informative)

          by Azoth's Revenge (82601) on Monday April 04, 2005 @04:47PM (#12137548)
          I'm currently using Rails for a project at work using PostgreSQL as my DB. Everything works fine with PostgreSQL in place of MySQL except sequence names. Rails assumes that a person creating a table will use something like (id serial primary key, foo ..). the serial keyword creates a sequence that is something like tablename_fieldname_seq. I wanted to have plural table names but singular sequence names. No way to change it by default. Also rails assumes one table one sequence.
          The Oracle abraction for active record has a way to specify the sequence name, but the postgres one doesn't I hope that this will eventually be rectified.
  • by scottsevertson (25582) on Monday April 04, 2005 @12:48PM (#12134870) Homepage

    At the Milwaukee No Fluff Just Stuff conference, I was invovled in a lunchtime conversation with Justin and [Pragmatic] Dave Thomas [pragmaticprogrammer.com] about this subject, just days after Justin completed the Ruby code.

    The concensus at that point: it probably wasn't a difference in *execution* speed, but smarter data retreval strategies used by Rails persistance layer. While Hibernate has excellent support for lazy loading, both developers thought that Rails was being *lazier*.

    Justin's new numbers also point to faster caching in RoR's persistance layer: while both applications performed about equally without pre-cached data, RoR performed 20x better than the Java stack with cached data [both versions using similar caching strategies].

    As for those questioning Justin's java skills: he's one of the best programmer's I've had the privilege to know, one of the best speaker's I've listend to, and is freaking hilarious to boot. He's the co-author of O'Reily's Better, Faster, Lighter Java [oreilly.com], and he regularly speaks on advanced Hibernate, Spring, and a bunch of other Java topics.

    He also points out a *significant* decrease in Lines of Code[Java:3293 RoR:1164] and Lines of Configuration [Java:1161 RoR:113]. While not an accurate gauge of effort, it is another point in Ruby's favor.

    Last point for Ruby: Every single *top notch* Java programmer I know is at least playing with Ruby and RoR, with a large percentage [>50%] transitioning to Ruby as a first choice for new project work.

    Don't call it a toy until you've played with it. There's some pretty convincing evidence that Ruby/RoR can beat Java for development effort, and now we're seeing it can beat it for performance, too.

  • 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 MarkWatson (189759) on Monday April 04, 2005 @01:04PM (#12135021) Homepage
    I earn most of my living writing custom web apps using (usually just part of) the J2EE stack. I love J2EE because it is rock solid - debugged web apps seem to run forever :-)

    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 :-)
  • Zope 3 (Score:4, Interesting)

    by Lodragandraoidh (639696) on Monday April 04, 2005 @01:30PM (#12135306) Journal
    I wonder how Zope 3 (python web application framework+more) compares to these?
  • by FigWig (10981) on Monday April 04, 2005 @01:54PM (#12135598) Homepage
    Java Trails is a Java version of RoR. A domain driven collection of tools that allows you to quickly get a CrUD web app up and running. Since it uses Spring, Hibernate, and Tapestry you have complete flexibility to customize code if trails doesn't do what you need.

    https://trails.dev.java.net/ [java.net]
  • 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.

  • Show me the code (Score:3, Interesting)

    by MSBob (307239) on Monday April 04, 2005 @02:19PM (#12135867)
    So.... I should make my next platform decision based on some guy's blog where he quotes some suspicious looking numbers within some unknown domain space and refuses to open the source code for public scrutiny? The Ruby trolls are really out in full force lately.
  • by melted (227442) on Monday April 04, 2005 @02:24PM (#12135918) Homepage
    It does not support Unicode. No unicode strings, no unicode regexps. So if you write your apps with l10n/i18n in mind, Java is still your best choice (or .NET/C# if you're on Windows).

    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.
    • Code Completion (Score:3, Interesting)

      by Paradox (13555)
      Ruby does not have a canonical IDE, unlike Java.

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

  • Trails Video (Score:3, Informative)

    by Mindbridge (70295) on Monday April 04, 2005 @03:46PM (#12136777) Homepage
    Trails has been mentioned earlier as the Java copy of RoR. You will probably find the following video [java.net] pretty interesting -- it demonstrates how quickly one can develop an application with Trails. It is a part of Chris Nelson's weblog [jroller.com].
  • by FatherOfONe (515801) on Monday April 04, 2005 @05:50PM (#12138272)
    I would read the article but the site is down.

    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.

    • Wow. Well, just a quick history of the post: I wrote an app in Spring/Hibernate. I then, as an experiment, rewrote it in Rails. I liked the result, and blogged about it. Not "everyone must dump Java right away", just "I had a good experience doing this". The blogosphere demanded a more concrete comparison. I provided those numbers. I have not stated anywhere that these are reference implementations, that they are the fastest things available, etc. I did pretty clearly explain the requirements in the l

"It is better to have tried and failed than to have failed to try, but the result's the same." - Mike Dennison

Working...