Ruby on Rails 2.0 is Done

Jamie noted that ruby on rails 2.0 is done. In addition to upgrade and installation instructions, the article lists a number of the more interesting new features in the release which appears to be quite extensive.

ORM still broken?

I wonder if they still disallow proper database design by having a requirement of an autoincrementing number for the primary key.... The Rails developers could learn a thing about databases. Start here: http://en.wikipedia.org/wiki/Database_normalization [wikipedia.org] . Yes I know that a serial/autoincrementing key makes it easy for the app... it makes it a lot harder for the DBA in a lot of cases.

RRN?

Back when I was a young whippersnapper, we called that thing a relative record number!

Re:ORM still broken?

People have discussed this over and over and over again. I presume you're talking about support for composite primary keys. They aren't necessarily a good thing. Go read http://rapidapplicationdevelopment.blogspot.com/2007/08/in-case-youre-new-to-series-ive.html [blogspot.com]

I don't even consider normalization taken to the extreme, to be a good thing. It's a trade off, just like everything else - what you gain by normalization, you might lose in the form of added application complexity, or perhaps even something else. Just because normalization is "good" according to ivory-tower database theory, doesn't mean that anything that isn't fully normalized is "bad" or "broken".

"Yes I know that a serial/autoincrementing key makes it easy for the app... it makes it a lot harder for the DBA in a lot of cases."

Can you explain what exactly it is that makes it a lot harder? (And isn't a DBA paid to do his job?)

Re:ORM still broken?

That's great for you, but Ruby on Rails is not - and isn't intended to be - a framework for redundant distributed DB applications. Ruby on Rails is not trying to be the thing for everybody. And that's exactly what makes it so powerful and easy. Indeed - turning it into something for everybody actually makes it worse. I'd like to see some proof that composite primary keys are so important in web applications. So far I've seen no convincing evidence. Despite all the complaints about composite primary keys, new Rails websites are written everything, even by high-profile organizations like IBM, NASA, Oracle and Yahoo. And they seem to function just fine.

If you really, really, really, really need composite primary keys, you can still fallback to raw SQL queries in Rails.

Re:ORM still broken?

If you do a search for "composite keys rails", hit #1 is this [rubyforge.org], a gem written by a fairly prominent ruby programmer that makes it trivially easy to use composite primary keys within ActiveRecord. My guess is if you actually cared about this issue, rather than just raising it as a canard to bash Rails with, you would have found this solution to your problem and wouldn't be posting here

Re:ORM still broken?

"Holy. Crap. You're not the guy that writes Active Record, are you?"

If you're referring to DHH, then no, I'm not him. My stance isn't as extreme as his ("database is just a big hash") but I do agree with some of his points. Transactions = good. Foreign key constraints = good. Stored procedures = only use when absolutely necessary. Normalization = weight between pros and cons in application code complexity and data redundancies. Etc.

"The thing a lot of OSS developers seem to forget is that many applications are primarily for data processing with user interfaces thrown on top. I.e. Not every damn "web app" is a blog or wiki, where it's primary purpose is to be a web app."

Not every, but *a lot* of them are. Very often they're systems for displaying, storing and retrieving small to moderate amount of information (unless you're working on a really really big multi-million system).

"Fact is that, if Rails wants greater acceptance (and, yes, I realize it is already widely accepted -- I'm talking about continued growth), then it's going to need to support things like composite keys. Why? Because people use them, and the application may have come years before the web interface."

I don't think so. I'm pretty sure that people complain about composite primary keys because it's so easy to complain about. Most of them probably wouldn't consider using Rails even if it fixes all its "flaws". *
There was a time when I took all Internet complaints very seriously. I worked very, very, very hard to meet peoples' demand, and I did it for free. In the end, it didn't help. Whenever I publish a fix for one complaint, they complain about other things. It's an endless cycle. The complainers can never be satisfied no matter what I do.
For example, people complain about memory usage in Rails. I've developed a way to reduce the memory usage by 30% [plan99.net], and look - very few people are interested! The people interested in my work are extremely disproportional to the number of people complaining.

* But by fixing Rails "flaws", you've just made it worse. The reason why Rails is so great in the first place is because it's a very specialized framework. It's not trying to be the thing for everything, like J2EE. If you make it the thing for everything it'll be a lot more painful to work with. It's like saying that your television can't wash your clothes. While it's possible to make a television that does that, it would be a royal pain to make and to work with.

Re:ORM still broken?

When you as a DBA use anything other than a surrogate primary key, you are making the exceptionally dangerous assumption that the client has the correct understanding of what their model entails, that there will be no exceptions to the rules of that model, and that the model they gave you will never, ever change.

Borrowing from your SSN example, let's say that your client tells you the main way they identify customers is through the SSN, and you go by that, and then there's a case of identity theft and the customer's SSN number has to be changed? Now you've got potentially thousands of records with a bad primary key that you have to change (and mitigate constraint issues as well). What if privacy issues require the company dropping SSN's as an identifier, and now the company will be forbidden from asking customers their SSN's? You'll no longer be able to generate primary keys compatible with the same ones used before.

What truly separates a good DBA from a bad one is the good DBA's ability to anticipate change, design for change, insulate existing stuff from change, and basically save the client from any flaws in their own conceptual model (while making it look like they've followed the client's conceptual model to the letter). A bad DBA simply trusts whatever his client says and believes it to be correct and forever immutable.

Re:ORM still broken?

If the client says that "orders have order items, numbered 1,2,3,4..." then your model should have (ORDER#, LINE#) as the compound key for order items. If the client says "customers are identified by an arbitrary customer number", then it's okay to use an artificial ID. If the client says "customers are identified by SSNs" then that's your key.

I hate to feed the cowards, but I just cant let this go.

You are completely incorrect.

If your domain model describes the way an actor finds an entry is by Order# and Line#, that should in no way, shape, or form decree what your technical artifacts look like.

The correct thing to do in that case is to have a unique, opaque, identity key (numeric or guid, just so long as its unrelated to the record data, and has no additional meaning beyond the unique value of that record).

Then you can also add unique constraints or indexes to the composite key, and/or you can enforce that unique constraint in the application. Or both, for the smart ones.

But you need to have a unique way to identify the record THAT IS NOT SUBJECT TO CHANGE. In your example, you could re-order the lines, or one line could have been a mistake and you need to move it to a different order.

If you've used composite keys on order# and line#, then you've got alot of cleanup work to do after your change.

If you've used proper opaque identity keys, then you just change the data, and there are no side effects.

Since in that case your joins are also done on the identity keys, your relatinoships are stable even when you change order# or line#.

The SSN one is even worse. I can guarantee you that if you do that, someone will have the wrong SSN, and it will need to be changed in your data.

If you've used SSN as the primary key, then its a pain in the ass, and you have to do data integrity cleanup.

If you've used a proper opaque identity key, then you just change the SSN, and there are no side effects.

This is stuff you learn the first time you write an app as a junior developer without a mentor, and use SSN as a key. A year or two later you come to regret it, and the lesson is learned for a lifetime.

Re:ORM still broken?

That stored procedure is awesome (well, it actually isn't very good sql, but it doesn't matter right now). As the developer, you just need to worry about passing the monster name and the database spits out everything you want.

If you do most of the logic in your stored procedures, it makes it easy to bolt on new features written in various languages. If you decide to have a perl script for a cron job, you just call the same stored procedures your ruby app is calling. If you want a windows front end for your admin staff, the windows app calls the same stored procedure too.

Once you bury the database logic in the application code, you have to rewrite it for every application. It is, in a way, a very evil form of copy & paste programming. Now every change in the database requires you to go into every single application and change something. Kinda like when you get slutty with your code and copy & paste it rather than abstract it out into a library.

And I'm aware stored procedures don't play nice if you are worried about cross-database issues because you sell the software. This only works when you get complete control over the application & database stack.

PS: MySQL stored procedures suck. Use a real database with a better stored procedure language.

Re:ORM still broken?

A DBA that uses composite primary keys does not deserve the title. You should never designate a primary key whose value can change. Use business keys for that.

Re:ORM still broken?

A DBA that uses composite primary keys does not deserve the title. You should never designate a primary key whose value can change.

You're assuming that all composite primary keys use values that do change. That's highly unlikely, given the number of tables in the world filled with historical data. That said, I agree (for other reasons) that surrogate keys are much better.

Re:ORM still broken?

Making the huge mistake that everyone would only ever want to do something your way is how you kill a programming language.

What a relief... As a lisper and rubyist, I'm glad to hear that Python is going to die! Good riddance!

Re:You don't have to use ActiveRecord

Yeah, and thats what I don't really like about frameworks in general. They have all of these awesome cool fast easy to use things built in. But sometimes you discover that your needs are too complex for the framework, and someone instantly replies " you don't have to use feature X". Well sooner or later you aren't using many of the cool features of the framework anymore. So why are you using the framework?

Re:You don't have to use ActiveRecord

I agree. That's why I build all of my computers by hand with raw transistors and whatnot.

Fresh Meat!

Fresh Meat, full of bugs, for the hackers to hack.

If you desire a secure system, do not place a large, immature body of code in the line of fire on the internet.

Too bad I just switched to Python

This new antigravity [xkcd.com] feature is astounding.

I don't understand the fuss.

I don't understand the fuss behind Ruby on Rails. Ruby is a programming language. Rails is a framework. Frameworks are a dime a dozen. Is RoR all that wonderful or are we being marketed-to?

Re:I don't understand the fuss.

You are, or at least so far as hype == marketing.

Re:I don't understand the fuss.

"Sure, but that's because Ruby is a real VHLL. You could also have achieved that effect by switching to Perl or, if you don't mind thinking in object-oriented terms about absolutely everything (and can put up with syntactically significant whitespace), Python. That doesn't answer the question about Rails."

Uhm no I don't. I've programmed in Perl far longer than I've programmed in Ruby. I only started with Ruby about 2 years ago. I have experience with mod_perl and stuff like Template Toolkit. I have experience with Python. And Ruby on Rails *still* beats everything else I've used.

It isn't just Ruby, it's also Rails. It's the entire package. Rails is not just any framework, it's an entire design philosophy. It's opinionated software. It's Don't-Repeat-Yourself. It's REST. It's convention-over-configuration. All this stuff together makes me much, much more productive. Ruby on Rails actually makes web application programming more fun than desktop application programming.

Re:I don't understand the fuss.

"Web guys" will never understand the hype behind RoR. For the average PHP coder, RoR is slower and more restrictive... A hindrance. To a software engineer, however, RoR's great use of design patterns and best practices compliments what they should be doing already. Just as an example, if you're not writing unit tests, then you aren't very serious about your software to begin with. RoR's test facilities will bore you and nag you death. What Rails does is force you to consciously decide to not do something you should probably be doing, like testing. If MVC and encapsulation mean nothing to you, then RoR can't help you much. You still need you own discipline, or you can still write abominable code. RoR embodies many practices from how the big boys write software, few from the basement hackers.

Re:I don't understand the fuss.

Please just try Rails for a little while. While Rails has its flaws, overall it's a highly productive framework - and much of the credit for the terrific code clarity goes to Ruby, which is much more powerful and dynamic than almost any other mainstream language(other than maybe Javascript)

Some things to read about and try within Rails:
* ActiveRecord's ability to introspect the DB schema at runtime. e.g. autocreating the method to allow: User.find_by_name('Joe')
* ActiveRecord's magic-fields, e.g. created_at/updated_at
* the ActiveRecord associations, and the easy DB queries that come with them, e.g. @user.posts.find(:all, :conditions => {:status => 'pending'})
* the scope_out plugin, which provides some nice additions to 'with_scope'. e.g. in the Post model you could do scope_out :pending, :conditions => {:status => :pending}, and then be able to change the previous example to:
@user.posts.pending
* ActiveRecord callbacks and the controller before/after filters
* the RESTful routing and easy links that come with it, e.g. link_to(@user.name, @user) will create a hyperlink to the correct URL for that user record's 'show' page
* the form/field helpers which also integrate with the routing, so you can now do just form_for(@user) - it will create a proper form tag for hitting either the create or update method for that @user, depending on whether the record has already been saved to the database - the form_for/fields_for block syntax is also very powerful, especially when you add your own form helper methods
* all the convenience methods provided by active_support, like 5.minutes or 1.month.ago
* Ruby itself - Ruby is simply a joy to code in. even if I were going to dump Rails, I would now strongly prefer to find a new Ruby framework(like Merb) than using another language

I'd strongly urge you to pick one or more of the PHP MVC frameworks to look at while you read about Rails. Most of them are copies or at least inspired off Rails to some degree, so they often use similar conventions. You'll see the difference between what's possible in PHP and Ruby - PHP doesn't come out looking too good at the end

Sites Moved to Rails?

OmniNerd.com [omninerd.com], a site I do hobby development for, is running on Rails 2.0. We switched over from PHP this fall and site maintenance has been a dream since. Our site has even survived a few Slashdottings and Diggs since the switch, which used to murder it before. (Granted, the PHP code wasn't the best.) I've heard the "doesn't scale" debate a million times, but I'm curious if there is anyone out there who has recently moved a project from one language/framework to Ruby/Rails and whether you're glad you did or if it's been a nightmare. We're a medium-to-low traffic site with big surges every few weeks and it's worked well for us.

Re:Sites Moved to Rails?

We do millions of searches a day at yellowpages.com [yellowpages.com]. One day the order came down that the site was getting rewritten, on a hard deadline. In four months 125,000 lines of Java became 14,000 lines of Ruby, and yellowpages.com became (most likely) the second largest Rails site on the internet.

The site scaled just fine because we have a team that knows what they're doing. Above all, they did research. They wrote prototypes in other frameworks before settling on Rails. They benchmarked different features and decided what to turn off. Rather than create one giant dumb app, we have a web-tier app for interacting with the user, and a service tier for processing searches with our search cluster.

Anyone noticed people who say "Rails doesn't scale" never tried to scale it? I am part of a team that has successfully scaled to the second largest Rails site on the internet, and I will always tell people who say "Rails doesn't scale" that they have no idea what they're talking about.

Re:Sites Moved to Rails?

11,000 requests in one second.... wow, that's huge!

How many did the system respond to?

I hope the linked site isn't running it

I am like the 10th comment and it is already slashdotted!

Science

Okay, all I see on here is negative comments, what ever happened to the concept of "the right tool for the job"? Ruby on Rails is a gem (excuse the pun) in the realm of bioinformatics and chemical informatics. I don't need to be concerned with "scaling" when I am building a site with a maximum of 10 users. For labs and small companies everywhere needing to create and support small or large databases, RoR is fast and easy. It also has major industry backing from the likes of IBM and Apple. It may be a bigger problem for high-volume sites, but I have found it extremely useful. I am using it on the backend (for data management - the data is exported from the database to the legacy perl system daily) for sites like http://www.drugbank.ca/ [drugbank.ca] http://www.hmdb.ca/ [www.hmdb.ca] and on the frontend for sites like http://hmdb.med.ualberta.ca/foodb/ [ualberta.ca].

I guess they didn't fix the scalability issues

Perhaps a web development framework's web site should be designed in such a way that it can handle a burst of traffic from Slashdot.org and Digg.com.

Otherwise, one might think that RoR doesn't scale.

Re:I guess they didn't fix the scalability issues

I prefer django over RoR hands down. I drank the RoR cool aid about 8 months ago, started working on a couple projects... after the initial "oh wow, that was easy to get started" RoR got significantly more difficult, I didn't find the documentation particularly helpful, and things that I thought intuitively would work and made sense were "not allowed" because the RoR conventions forbade them.

Enter django. Wow, all the power, none of the "Hansson said this is how it should be, so no other way is possible" handcuffs.

To me django is a much better designed framework, it has in my opinion a much more powerful database abstraction layer, it is more intuitive too. working in Rails for > 4 months I still had to look up the syntax for doing activerecord queries every single time. django's query syntax just makes sense to me, and is much more intuitive. And what can I say, I've never enjoyed making HTML forms more than using the newforms library that builds them for you (oh yeah, and validates them for you, and marshals form input into objects automatically...).

Also, the simplicity of setting up a production django server is so much easier than RoR. Sure, once you start having lots of traffic, building a fully scalable system is probably going to be similar. But to set up a single server for a low traffic site, or a small company intranet, apache+mod_python is great. mod_ruby has huge performance issues, ror+fastcgi in apache is atrocious, mongrel can be ok.. but then you still have to set up apache in front of it, and its not a simple apache set up as you have to configure all the proxy stuff...

Besides the fact that python is ~10 times faster than ruby (just at the interpreter level) and you've got yourself a nice little powerful system with django.

Maybe once django hits version 1.0 they'll get a bit more hype, but I've actually seen more posts on this story saying "check out django" than I've seen people saying they absolutely love rails.

Does it still require Mongrel?

Or rather, since I haven't been keeping up with the development process, perhaps I should ask, is there a viable apache 2.x module for ruby that allows one to run RoR sites without relying on mongrel/other web servers?

Because, frankly, if it can't be run on apache 2.x, I (and the company I work for) won't touch it. We have already seen the scalability nightmare that RoR was, of course, so obviously we're a bit skeptical about performance optimizations. (:

Note: I have nothing against using new technology, even if it requires learning a new language, but when one has a hundreds of sites that require web server A, and a framework requires the shoehorning of web server B, well, the aforementioned framework loses its appeal.

At this point...JAF

RoR is just another framework now. Almost everything has caught up to it. The biggest question to ask yourself is "Do I want to program in Ruby?". If the answer is "no" then meh who cares about this.

The server's...

Apparently the server's done (like Nixon, not like Dinner).

Scalability

Having worked on web sites using Rails in a previous job, I have to say I love many things about the framework. Like Ruby, it gets a lot of things right, and a few things very wrong. On the whole, I found it great to work with.

Recently, a friend told me that scalability was a major concern with Rails. I am not aware of any issues with that with the sites I worked on (which are pretty high traffic), but I left the project before the sites went live, so I can't say for sure that there weren't any issues. Can anyone here chime in on whether that has ever been a problem with scalability in Rails, what the causes of the problems are, and whether Rails 2 does anything to fix them?

It is a pity ...

that one cannot simply deploy RoR on Apache. That is what remains the big advantage of perl and especially PHP-based solutions and frameworks.

Why the hate?

Seriously.. why does Ruby on Rails get so many people so fired up? If you don't like it, don't use it. If you do like it, feel free. There's no one-size-fits-all solution, but for many people Rails comes pretty close. If you're not one of those people, there are plenty of other frameworks and languages.

Why do people in any kind of IT have such huge egos? It's counterproductive and at the end of the day, if you're making the client happy, and that makes your boss happy, you've done your job.

To everyone harassing rails..

..use something different. I don't care what you use, or why you use it, as long as it works for you. And read this blogpost [blogspot.com] by Gilels Bowkett, which should tell you a thing or two about personal preferences. There will never be an agreement on this.

Rails 2.0 Guide in English and Spanish

I've published a guide to Rails 2.0 written by prominent Rails blogger Ryan Daigle. It's available in both English [peepcode.com] and Spanish [peepcode.com] as a DRM-free PDF.

Ruby is interesting, but the syntax is awful

Ruby looks interesting in a lot of ways, but the syntax is rather painful. Is there something similar with a more smalltalk like syntax?

So what scales...

For all the talk about ROR's questionable scalability I'm personally interested to hear what people do consider a highly scalable framework? The company I work for uses Fusebox (we are weening our application code off Coldfusion) and are likely going to move to Zend's framework. But I'm looking at working on a personal project and would like a framework that balances accessibility (I'm a fairly new to PHP, I do systems work) with scalability.

I started doing my own research this week so I was excited to see the ROR discussion and hoped it might be enlightening. I know the BBC uses Ruby on Rails at least internally [bbc.co.uk] (and apparently a custom Rails-like Perl MVC externally?) and the community support for ROR is excellent (I've been reviewing documentation to help narrow my decision).

Since from what I've read the Zend Framework isn't as accessible (and the documentation seems a bit more high-level) I've been mainly reading about Ruby on Rails, CakePHP, Django, Code Igniter and most recently Symfony.

If Ruby on Rails isn't considered particularly scalable, what is?

"Done"?

Referring to software as "Done"... turkeys maybe... but software?!

The value is the content

The language isn't much use if there aren't blogs to fill the websites with content. Don't forget the millions of blogs, diaries, instant messages, home videos, & home photos that really make the current languages valuable.

RoR 2.0, Web 2.0, Hype 2.0

Rails is fine if you want to do another Basecamp [basecamphq.com] or similar 37signals [37signals.com]-type project. It's even better if you want to whip out an amazing number of structurally identical, common-organization Hype 2.0 apps. But just ask the folks at Twitter [twitter.com] how well its database access scales to meet demand - it almost put them out of business. Several times. Rails is a poster child for the perils of an application-specific language being used as a general-purpose one.

A lot of things that I read obout it remind me of Python in the early days - but I don't recall Guido van Rossum being so Great Leader-ish, and there's also the difference that Python actually can be used for an amazing range of applications. Ruby can too; it's a beautiful language - until you cut its balls off with Rails.

Merb?

Maybe you should give MErb a try? Merb, more ruby, less rails [merbivore.com]

Re:Compound Keys

I doubt it.. Rails has never been known for actually using the database for more than a flat file... One of the reasons it can't scale.

Scaling matters if you're Digg. Are you Digg?

While Rails might not be my first framework of choice to implement Digg in, I prefer to build sites which actually, you know, make money by solving problems for paying customers. When you do that, you don't really have to worry about scaling to infinity and beyond, but you do have to worry about expressiveness, maintainability, and time to market. (If you have too many customers relative to servers, heck, easy solution there -- the engineer in me says "just throw up more boxes", but the businessman in me says "pay somebody to worry about it so I can go back to counting my benjamins".)

I have a Rails site, my first (hopefully of many) for my small business, which plugs along at about 20 requests a second in tests. If I could saturate those 20 requests a second, I would quit my day job on the spot. Scaling? Eh, who cares.

(P.S. Day job is writing enterprise level crud apps for Japanese universities on the J2EE stack. They worry a bit about, e.g., getting hit with 8k users signing in simultaneously during class registration. You know what we do? Exactly what I'd do for a Rails app in the same situation ("don't do anything stupid like an n+1 queries loop, cache the important stuff, and buy enough hardware for the job"). Only difference in Rails is I have never wanted to poke my eye out with a spoon while writing it.

Re:Scaling matters if you're Digg. Are you Digg?

Ever notice how those most "concerned" about scalability tend to have never profiled or benchmarked their own code? ... or understand why you want to scale horizontally, rather than vertically? Whenever I build services that can handle 120,000 requests/sec., they usually just end up being 99% underutilized. Everyone likes to think THEY will be the next MySpace, with no server budget apparently. I highly doubt that any who argue Rails can't scale has ever had to deal with real distributed clusters. The database cluster will have many more scalablity issues than the webservers. This is such a non-issue, I cannot believe it. If you can scale JAVA!!!... You know what I mean.

Re:Scaling matters if you're Digg. Are you Digg?

Every time a RoR article hits Slashdot, there is a scale/speed question that gets raised. Realistically, there are a ton of things you can do to get performance where you want it to be. The first is to dump mongrel and use FastCGI or similar. FastCGI is 3-5x faster than mongrel. Mongrel is great for low traffic sites, and for dev, don't get me wrong.

The upper limit I see with RoR/FCGI is around 2500 requests per sec, for a 'is the server alive' ping, that simply returns 'Yes'. Typical, results are in the ~100 requests per second range with moderate db access, and rendering to xml or html. 100 requests per second was enough to handle a 24 hour media buy on the frontpage of myspace for example (100,000k unique visitors-ish).

Moving your static assets off of your server and on to S3 or another CDN is obviously a big help here, so your server/bandwidth is only taken up with requests that need/affect the db. From the example above, with the MySpace media buy, the total for that day was $20-30 I believe in bandwidth costs, and this was a site with a video mixer that had tons of images/video/mp3 and large flash objects. Obviously, mongrel shouldn't be delivering your assets locally anyway, apache/lighty etc should be.

Ultimately it comes down to design and caching when it comes to getting that top performance out of it. My 100 requests/sec wasn't using MemCached or fragment caching, and the mysql db was local. Caching in Rails is a little less than helpful for highly customized for each user sites, but there are plugins that extend it like extended_fragment_cache(ing?), that allow you to templatize things like ID's, etc. Think of say a forum topic listing, where only the topics change as you paginate. With extended fragment caching, you basically draw the page once, and then pass in a hash of the variables that replace the placeholders each time you draw a new page.

Another big thing with ajax sites, is to use link_to_remote with the :update => 'some_div', rather than using the rjs/render :update stuff in the controller. escape_javascript is one of the BIG performance issues in Rails, as it is basically just multiple gsubs. Designing around that is a big win. A native C escape_javascript should be a high priority for the rails/ruby devs, with optimization for the memory allocations (ie. scan the string to see how much it will grow, allocate, and just do one pass to expand).

Re:this is fantastic

Moderator obviously didn't read GPP.

Re:this is fantastic

My god I wish I had mod points. That's the funniest thing I've read all day.

Re:Python on Rails... instead..

Check out django. As that article mentions MVC efforts can become overly restrictive very easily. If you ask me, Ruby on Rails has already crossed that line. django is mvc as well so someday might go down this path, but it hasn't yet.

django provides all of the ease of Ruby on Rails, it is powerful, it provides even more tools than Ruby on Rails in my opinion specifically for web work. And I don't feel like I have handcuffs on when I'm developing in it.

I started building 2 projects in Ruby on Rails ~8 months ago. These were existing PHP systems which had become overly cumbersome and were in serious need of a redesign/rewrite. Rails seemed to provide everything I needed, began porting... got about 30% done and started running into serious roadblocks that were there by design in Rails.... I aborted the porting, and started looking for another framework, found django... the 2 projects are now 100% ported (took less than 1 month each).

django was also significantly easier to set up for production than my experiences with rails (apache? lighthttpd? mongrel? the recommended web server for rails changes every week...) modpython+apache is dead simple to set up and rock solid (apache+rails requires fastcgi which was constantly crashing, unstable, and basically doesn't work)

obviously I'll get flamed for this as RoR has way too many fanboys, but as far as a concise, powerful, well documented, easy to use, flexible, and enjoyable development experience nothing gets close to the last 2-3 months working with django.

Re:this is fantastic

Sheer genius, funniest post I've read in ages.

The fact that no-one has modded this hilarious post up only goes to illustrate how broken Slashdot's moderation system is.

Re:PFFT!

Albeit with a shitty syntax and a total lack of style, Ruby's semantics are very similar to LISP. It's the toy languages with toy abstractions that force specific paradigms up your ass, such as Java, what you should be bashing, fellow Knight of the Lambda Calculus.