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

    by ajs (35943) <ajs@@@ajs...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...)
  • by Paradox (13555) on Monday April 04, 2005 @11:44AM (#12134247) Homepage Journal
    The blog is not a ruby-on-rails application.
  • Mirror (Score:5, Informative)

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

  • 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 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.
  • 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:Ruby is a toy (Score:5, Informative)

    by Paradox (13555) on Monday April 04, 2005 @12:05PM (#12134460) Homepage Journal
    There is no serious caching
    Incorrect. In fact, RoR's caching complete destroys Java's caching in Justin's comparison. You can read about Rails' caching here. [rubyonrails.com]
    No serrious transation capabilities
    Obvious jokes about your spelling aside, Ruby provides these already. Rails does not need to provide them.
    or messaging mechanisms.
    This complaint is flawed. However, Rails can accomplish what you're asking for if you want to. It's just that, assuming I understand what you're parroting, it's a very bad idea to do it.
    hype and buzz.
    Only if you don't bother to find out the truth.
  • Re:Security (Score:4, Informative)

    by Tobias Luetke (707936) on Monday April 04, 2005 @12:07PM (#12134472)

    Nice FUD... Except that its made up. Rails is very secure by default (uses pepared statements and things like this).

    It does whatever it can do to make the framework part of the application secure and even offers a book on security on the hieraki bookshelf for the user side of things: Securing your Rails application [rubyonrails.com] .

    This is a great example of rails quality documentation. have a look at the bookshelf itself: Hieraki bookshelf [rubyonrails.com]

    And the application which powers it is open source (MIT) at www.hieraki.org [hieraki.org]

  • by Paradox (13555) on Monday April 04, 2005 @12:08PM (#12134484) Homepage Journal
    There was a brief example of this on ONE of the wiki-based tutorials in which the person posting the tutorial didn't use Rails's built in SQL search features or safety features. Because of this, there was an SQL injection hole. It was promptly corrected.

    No amount of safety can make up for novice mistakes. Rails provides everything you need to make secure webapps, and it lets you do it painlessly.
  • 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
  • Re:Wait..... (Score:1, Informative)

    by Anonymous Coward on Monday April 04, 2005 @12:12PM (#12134518)

    PHP is a general-purpose scripting language. You can write shell scripts in PHP. You can write GUI applications in PHP. It started off as web-only, but that hasn't been the case for years.

  • 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 Anonymous Coward on Monday April 04, 2005 @12:13PM (#12134527)
    Actually, this is possible. Rails complains the most about having your primary key be something other than the field named "id". A snippet from a recent post on the Rails ML:

    class XXX "Person", :foreign_key => "person_id"

    def self.table_name() "YYY" end

    def self.primary_key()
    "myprimarykey_id"
    end
    End

    So, you can tell active record what the primary key is for each model, and
    you can spell out what foreign keys to use for has_many and belongs_to,
    etc., as well as what the table name is.
  • by dtfinch (661405) * on Monday April 04, 2005 @12:15PM (#12134541) Journal
    # of clients can be misleading. If it's the number of daily users, it could mean as little as 10 requests/second in an 8 hour day. Just about anything can handle that kind of load. If it's the number of simultaneous connections, then with a gigabit connection you could only serve about half a packet a second to 250000 clients, and I know Java doesn't scale to 250000 simultaneous threads. If they're talking about a horizontal scaling, as in a cluster, then load comparisons becomes almost meaningless without specifying the hardware. Depending on the application, with 10x servers you can usually handle nearly 10x the users, no matter what language you're using.

    Notice that Slashdot is written in Perl, with nearly all dynamic pages. According to the FAQ, which may or may not be up to date, they have 8 single processor 600mhz PIII web servers and 1 quad 550mhz xeon MySQL server.
  • 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 aziegler (201013) <[halostatue] [at] [gmail.com]> on Monday April 04, 2005 @12:26PM (#12134646) Homepage

    Full disclosure: I don't particularly like the Rails way of doing things with databases, because it bases its data interaction semantics as if MySQL were a good (rather than an "easy") database.

    That said:

    1. Ruby has SOAP capabilities and it's built into the core of Ruby (SOAP4R). Just because someone has not yet seen fit to mix ROR and SOAP doesn't mean it can't be done.
    2. Ruby can do RMI/remote invocations through DRb or other mechanisms. Of course it can't do Java RMI without a JNI connector, but those JNI connectors are available -- and there's even a nascent JWDP connector for additional interaction with Java.
    3. There is some queueing technology available for Ruby. I haven't had a need for it, but it's available. Or buildable.
    4. ROR prefers you to design the database from scratch, but it certainly doesn't prevent you from using an existing database and doing a bit of extra coding to make it Just Work. The good thing about ROR is that it uses sane defaults to make the common brain-dead simple. You can manually implement a mapping. There might be room for an easier mapping mechanism in cases like this (rather than defining self.table_name and self.primary_key), but as ROR is still an evolving framework, that's not a big deal.

    The assessment on the Rails blog is, I think better. The numbers are impressive but meaningless -- there are tweaks that can be done in any case. The real point is that this shows that Ruby Isn't Slow and that Rails (or any other application environment) can be used in a production environment.

  • by Anonymous Coward on Monday April 04, 2005 @12:29PM (#12134678)
    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 you can't really do yourself without considerable effort. Also, I believe Hibernate 3.0 has an equivalent to iBatis (being able to map straight SQL without abstraction), but I haven't tried it yet.

    I don't trust/want something to auto generate my sql tables and such based on my objects.

    You don't have to auto generate your SQL tables in Hibernate. Create your SQL tables first, and either auto-generate your mappings from the tables (using Middlegen), or hand code them. Or did you mean queries not tables?
  • by swimmar132 (302744) <(ten.rekcupknip) (ta) (eoj)> on Monday April 04, 2005 @12:31PM (#12134696) Homepage
    Sure you can.

    In the model for the class:

    def first_name
    fname
    end

    There might be a better way to do it, but that works.
  • 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.

  • Re:Application (Score:2, Informative)

    by gbevin (97924) on Monday April 04, 2005 @12:53PM (#12134919) Homepage

    Except that they were not written by the same people, so they both had to do the same effort of analysing the application. Also the features are quite different, for instance:

    1. Bla-bla List [blablalist.com] has a complete REST API that sits in the middle of the GUI and the actual web application.
    2. you can continue editing even if your session times out
    3. private sharing is done securely
    4. public lists have meaningful URLs

    So there's a lot more to compare than just a screenshot that doesn't do anything constructive and just tries to hype a concise part of the RoR version.

    The fact that Ta-da took 600 loc and Bla-bla 900 seems to be totally ignored by Rails advocates and they all keep chanting 'that screenshot says it all'. No it doesn't, since the loc factor is 2/3, not 1/14. Ta-da is probably just more verbose elsewhere, but that's impossible to compare since it's not open-source.

  • by scottsevertson (25582) on Monday April 04, 2005 @01:12PM (#12135086) Homepage

    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 stays mostly out of the way.
  • 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 Anonymous Coward on Monday April 04, 2005 @01:36PM (#12135385)
    I'm only in the process of learning Hibernate, so I'm by no means an expert. However, a couple comments:

    "I don't trust/want something to auto generate my sql tables and such based on my objects"

    You can generate tables from your objects, or generate your objects from your tables. Either way is possible with Hibernate. Personally, I create the tables and generate the objects from them.

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

    Hibernate does the same. In fact, I did that very thing yesterday. You put your named queries in the mapping file and reference them in your code. Works beautifully.

  • Re:Mojavi (Score:1, Informative)

    by Anonymous Coward on Monday April 04, 2005 @01:54PM (#12135597)
    After studying and playing with mojavi for a month or so, I went ahead and built an app in it, only to decide afterwards that, even with all the comments and documentation I left in the code, noone would be able to maintain it besides myself. For someone who doesn't already *know* mojavi, getting up to speed on how it all hangs together to make things work is a really steep curve.

    Admittedly, however, I learned a whole bunch of things about php that I never considered before playing with mojavi. I think if I were to build an app which I knew I would be the only developer that would have to revisit it in the future, I would do it in mojavi, but it is sort of overkill for most small projects.

    Now, if only that zestic cms built on mojavi was done....hehe.
  • 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]
  • Python folks always seem to minimize the importance of [anonymous code blocks], but in practice it is very useful/powerful and it can lead to very natural looking DSLs in Ruby.

    Oh, no question. It's the one thing that Ruby has that Python doesn't, and it's one that many developers (myself included) would love to have.
  • by Abcd1234 (188840) on Monday April 04, 2005 @01:56PM (#12135620) Homepage
    But the lack of a usable lambda feature in Python would mean that you can't pass around significant code blocks like you can in Ruby

    Well, this is just silly. I'm not a Python expert by any means, but even I know this works:

    def func():
    def my_code_block():
    print "Hello, World!"

    return my_code_block;

    f = func();
    f();

    What Python doesn't have is nice, clean, anonymous code blocks (ie, for anything non-trivial, you have to name them).
  • 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).

  • 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 Anonymous Coward on Monday April 04, 2005 @03:21PM (#12136504)
    Python and Ruby are different programming languages.

    http://en.wikipedia.org/wiki/Python_programming_la nguage [wikipedia.org]

    http://en.wikipedia.org/wiki/Ruby_programming_lang uage [wikipedia.org]

    They are both good languages, with useful features and libraries. If you've never tried either before, just take your pick of which one seems the best from a tutorial. They have some overlap with what type of stuff you can do with them (webapps, command line scripts, administration automation, etc).

    Ruby on Rails and Zope are different web application frameworks. Zope is written in Python and you use Python to program with it.

    With Ruby on Rails, you can get up and running pretty quickly. Zope has a bigger learning curve, and some would argue it is more powerful. That's really a matter of personal taste.

    Ruby on Rails uses the "Model-view-controller" approach to software. This is a traditional way to do things, and IMHO Ruby on Rails does a good job of implementing it for web applications.
  • by Abcd1234 (188840) on Monday April 04, 2005 @03:30PM (#12136595) Homepage
    Which would be why I said "What Python doesn't have is nice, clean, anonymous code blocks (ie, for anything non-trivial, you have to name them).". What you've shown me is a very nice example of syntactic sugar. But make no mistake, that's all it is.

    The real difference between Python and Ruby is that Python doesn't support true lexical closures. As such, it's not possible to duplicate your example, as you can't rebind the outer variables in Python... an annoyance, to be sure, but certainly not fatal, and it definitely doesn't prevent one from creating a Rails-like system in Python. In fact, it can be argued that Python's way is safer... fewer side-effects.

    Incidentally, I have to say, Ruby's idea of having 'yield' execute an implicit codeblock (as opposed to just passing the damn thing in explicitely) is one of the most braindead things I've seen in quite some time... talk about confusing code. I mean, if you're going to copy Smalltalk, at least do it right... yeesh...
  • 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 Tobias Luetke (707936) on Monday April 04, 2005 @03:56PM (#12136880)

    The best solution for this is memcached. It means that all sessions will be in memory and therefore blazingly fast accessible to anyone in the server farm.

    The database is a excellent second choice as well. I usually go with db based sessions first for convenience and move to memcached as soon as it is required. As always, dont try to make your app scale before you need it. I know its fun but just wait, you will have a much better idea where the bottle neck is when you hit one.

    I know this is a trick 99% of all projects never need to run across more then one box, never mind what management says.

  • by gnuman99 (746007) on Monday April 04, 2005 @04:11PM (#12137060)
    Make a view out of the stored procedure? Then you put the necessary code in the database to update/insert into that view.

    Rails assumes that each model is one table. In the database, the table can also be a view, but you have to add capabilities in the database to update/insert into that view if you want that functionality.

    Mappings should be done in the databases - that's what they are there for.

  • by mccoma (64578) on Monday April 04, 2005 @04:23PM (#12137192)
    The Java Virtual Machine running on Macs has always been questionable. Its not Sun's implementation and has not been as heavily updated by Apple.

    OS X uses Sun's JVM code which is tuned by Apple with some of the tuning being returned to Sun. Perhaps your thinking of the OS 9 JVM?

  • 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 jgehtland (873274) on Monday April 04, 2005 @05:59PM (#12138356)
    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 latest posting, and both applications meet the requirements handily. So, in sum, Rails solved my particular problem slightly better than Java/Spring/Hibernate. And the code is more fun (for me) to write. Is that really such a controversial statement?
  • Because... (Score:1, Informative)

    by Anonymous Coward on Monday April 04, 2005 @07:33PM (#12139172)
    They saw it, Geert. And they were dully impressed, but you didn't really do what you said you'd do.
    1. You used Lazlo. Your templates are 10x bigger than Tada lists. You may not count this, and that's great for you, but it's still code you have to maintain. If you were to add Tada's templates in with the count, the code count wouldn't go up nearly as much as Bla-Bla's would.
    2. You didn't implement Ta-da list. You implemented something kinda like Ta-da list optimized for RIFE. Were Ta-da list to be rewritten as a standalone app leveraging the current Rails (instead of being ripped out of Basecamp and used as a marketing tool for it)? 340 lines. Don't believe me? Check out taskTHIS! (and source [darthapo.com])*.
    3. You have to maintain your configuration, but you fail to mention that massive size as well. In rails there is almost none.
      [*]Please don't make too many comments about the quality of that code, it's a demonstration. It is not as perfect as it could be, and that works for and against it. It probably cold be smaller, it probably could be more bug free.
      So yeah, Geert. You won a contest you yourself made, set the rules for, and gamed appropriately. You are now eliagable for a cookie.
  • Re:Zope 3 (Score:3, Informative)

    by Ian Bicking (980) <{moc.ydutsroloc} {ta} {bnai}> on Tuesday April 05, 2005 @03:35PM (#12146606) Homepage
    Huh, highish rated posting with no replies, I guess other people are also curious. I know about Zope 3, but I haven't used it at all seriously.

    Zope 3 is really targetted at J2EE-like functionality. Rails is based on a You-Ain't-Gonna-Need-It philosophy -- it provides significant base functionality and a set of conventions, but the framework is not all-encompassing or intended to match J2EE feature-for-feature, nor as a framework does it really mean much outside of the web. This is by design.

    Zope 3 is really a whole design philosophy, kind of like J2EE. It makes heavy use of interfaces and adapters, which are intended to bring an increased level of formality to the development process. But it's not just an attempt to put static typing on top of a dynamic language; the techniques they use are fundamentally dynamic, and an attempt to utilitilize those formalisms as basic programming constructs. This is embodied in the idea of "adaptation", where instead of requiring an interface, you ask for a version of an object that implements the interface, and then you provide wrappers ("adapters") to translate interfaces.

    There's other ideas in there too, generally built upon these basic programming ideas. It's a framework of frameworks. It's also heavy on the idea of modeling, and of an applications that provide a window into your models. The entire scale and concept is very different from Rails. It's actually a little foreign to the Python community too. A lot of Zope 2's ideas were also foreign to the Python community, but the problem is that they were also uncomfortable and put people off -- I don't think people are uncomfortable with Zope 3 as much as unfamiliar.

    (Also, Zope 3 is a complete rewrite of Zope 2 and is very different, so most of people's experience of Zope 2 -- good or bad -- can't really be applied to Zope 3)

Testing can show the presense of bugs, but not their absence. -- Dijkstra

Working...