[tptacek]

I don't object to the "find the right way" comment, with one clarification: he's talking about the web framework.

Ruby is just fine for "just wanting to get it done"; we've used it to write an assembler that models opcodes as Ruby objects, a binary format description language, 3 different debuggers, a web proxy, a hex editor, a whole slew of crypto, a testing framework for the FIX trading protocol, Cocoa UIs, and god-knows-what-else. If you looked at any two of those packages, they might not appear to be written in the same language, let alone the same team.

Rails does not care what crazy Ruby stuff you have built for your specific problem domain. If you are doing graph-theoretic modeling with a custom Ruby library, Rails does not care and it will work fine.

But. If you have even the slightest difference of opinion with Rails as to how to handle a request or represent the URL parameters you're getting from browsers, you're in for a world of hurt. The things Rails has opinions about, it has strong opinions about. And it's a total passive-aggressive asshole about those opinions. It doesn't say no. It slowly punishes you instead. In particular, even though Rails 3 advertises that it has swappable ORMs, you'd be crazy to consider anything but ActiveRecord.

The nice thing about losing degrees of freedom is that you don't have to make decisions about them, so I tend to reject the idea that Python gets you home to your kids faster.

[patio11]

An example from recent experience: if you want your application to have multiple cache stores, God help you. I use cache stores to wrap NoSQL stuff in a consistent API that I'm familiar with, and since sometimes I want stuff to be retained indefinitely and sometimes I just need a memcached scratchpad, I have multiple ones. That has gone fine... until it didn't, in a very catastrophic fashion.

What I really, really should have done was write a thin wrapper over the existing Redis code implementing the three methods I typically need my cache stores to support (read, write, fetch -- that's it), then configured the cache stores on class load from a YAML file. This would have gotten me done in an hour.

Instead I tried spelunking deep into the dark recesses of Rails 2.3.10, how it loads environments and initializers, and two gems to figure out what was going on... and very nearly had to postpone shipping because of it.

Don't do that.

But when I'm doing things the Rails Way, yeah, pretty much peaches and cream. I've never had an issue with writing arbitrarily complex Ruby code to do things that are not in the "typical web application" purview.

[gte910h]

>Ruby is just fine for "just wanting to get it done"

Yeah, I explicitly said ROR there because its the web framework which is annoying when you want to ship. I think the language is pretty neat actually, 'cept doesn't have as many libs.

>But. If you have even the slightest difference of opinion with Rails as to how to handle a request or represent the URL parameters you're getting from browsers, you're in for a world of hurt.

Yeah, sometimes that "way rails thinks you should" is considerably more complicated than what you'd have to do on a PHP or Djagno project to just get that last mile in. I'm currently finishing up a iOS SDK/library that talks to both a rails and django backend, and while the ROR dev is more available, he often has to figure out the right ways to change things that the Django guy just splats out if he has to(and cleans up after we're integrated). The ROR solutions are often frustratingly complicated (want to add a field to this view? Naw you can't, we have to instead change the datamodel of that object and sorry we can't name this that thing you already put in the client, etc). We don't care about long term whatever this week. We just want a certain URL scheme and certain output to happen NOW so we can integrate the last couple chunks in before our announced press event hits us, then backfill with quality code at that URL later. It might just be I know the ruby dev better, but he seems he's probably the better programmer of the two as well (but I don't know the Django guy well).

Sure the rails methodology might be better if you are the type of the person who doesn't do things the right way when you're not forced to , but if you are the type who does things correctly, the Django is no more correct or less correct and canonical, except for those instances when where you just have to finish. So if we're adults, we can write good code most of the time and good enough code when we have to and get away with it on Django. On rails, yeah right. There was a Plone developer who said something once like "Python believes we're all consenting adults". I feel python web frameworks do, and ROR doesn't. (link to the AWESOME talk:http://www.archive.org/details/SeanKellyRecoveryfromAddictio...)

If I wanted bureaucracy, I'd go do a java serverlet. Rails feels more like religious doctrine enforced in code than bureaucracy, but it has that stink of java's "thou shalt use the X to do the Y or DEATH AND INFAMY will result". It's not an overwhelming stick mind you, but a slight odor.

Ruby on Rails DOES work. It just is frustrating in that it does not allow shortcuts, ever. Therefore, I feel it keeps you away from your kids before a commitment, where Django doesn't. I'm not saying "don't ever use it", and I dont' think people who KNOW rails will get enough out of swapping to do the swap, but if you know neither now, I'd go python/django.

Then again, if you're new to programming, the copious beware/here be dragons of ROR might be a better path to get used to not slacking.

[tptacek]

I thought the same thing after living with Rails in a shipping product for 2 years or so. We embraced Sinatra, which does away with all of your Rails concerns. Sinatra is still very popular; probably the most popular framework after Rails.

However, for my last several projects, I've been back in Rails and happy to be there. Once you understand why things work the way they do in Rails and stop trying to bend it to your own design, it turns out that they mostly got it right. It is, for instance, so much easier to code up preauth/postauth pages in Rails, or to implement permissioning.

[patio11]

I looked into Sinatra, entirely at Thomas' suggestion. My experience after coding up a toy web application was that, if I wanted to build a non-toy application, I'd end up building a half-complete, undocumented, poorly tested version of Rails 1.0 prior to actually being able to work on the stuff people pay me money for.

It is a wonderful microframework if you want to either a) build a web framework because you want experience doing it or b) have some huge honking system which you just want to drizzle a bit of glue code onto and expose pretty much unmodified to HTTP.

[danieldon]

Have you looked at Padrino? I recently experimented with it and was surprised that it was an extremely awesome middle ground, to the point where I'll probably use it for my next project. It's very fast, close to Rack and easy to use with Rack middleware, has Rails-style view helpers, has sinatra-style controllers, very simple and elegant mountable apps, a focus on DB agnosticism, among many other things

[gte910h]

Question: Have you experience with it on heroku? Does it work well there? Any difference between its behavior and the "normal case" of RoR as far as what heroku is designed for to your knowledge?

(Like I've said, got nothing about ruby, just don't feel rails is a good fit for the stuff I do; something lighter weight like this could be a good substitue on heroku).

[danieldon]

I haven't, but I know it works fine. Heroku is more of a Rack host than a Rails host, so any Rack-based framework (AFAIK, all Ruby frameworks at this point) run seamlessly on it.

[gte910h]

Amusingly, I don't recommend Django even for first timers like the guy, however I'm not usually one of those people who answers a different question when asked, for the same sorts of criticisms in some areas as I have about rails. I like itty bitty frameworks usually. Sintra runs on Heroku, and will definitely be brought up before I hear about another project about to be backended there.

Honestly, I think Rails will give you a cleaner project with most groups of devs. There is a lot to be said for that. I think if you took a lot of people who are successful as rails devs, they'd struggle with the "having your own opinions are necessary" issues you have when you hit the open country of python webdev, and not perform as well. If the guy asking is just wanting to make something, I think RoR is a better material, cept it can't do some things. I think Django is a less good "base material" which many people will make an inferior product, but if you're highly competent, it's softer, less rigid structure allows you to be a better rapid developer rapidly dealing with changes to environment and project spec.

I, particularly speaking, happen to be a rapid developer of pretty complex systems. A long rails project is probably going to be a better system, and is almost DEFINITELY going to be a better hand me down from someone else, but a Django system will almost always allow a small change.

Rails is building a house of granite with no other materials. Django is using a bunch of softer stuff.