Don't. Give them a month or so to start hating Rails. As soon as you attempt to step outside of what Rails is built for or need some new piece of functionality it starts falling apart, not only that but Rails is painful to scale.
As soon as you attempt to step outside of what Rails is built for
Rails is a tool for building database-driven websites. It does this well, and I'm confused as to how you can "step outside of" this. Admittedly Rails probably doesn't help you built a GUI application well.
or need some new piece of functionality
Wait, what?
How did you arrive at this conclusion? Rails doesn't ship with authentication, but there's no less than two (authlogic, restful_authentication) major frameworks for authentication, and countless smaller libraries or self-written tools. The same goes for uploading files (attachment_fu, paperclip), testing (rspec, cucumber, steak, shoulda, ...). The list goes on. Rails' active community is one of the main benefits of using Rails in the first place!
Rails is painful to scale
Rails is no more painful to scale than any other web framework. The bottlenecks for scaling usually come down to application design, not your ORM.
Have you ever even used Rails, or have you prejudged it based on posts by people who also have never used it?
Also, while scaling may be a non-trivial challenge, going to over ~100,000 page views a day (95% are between 8am - 6pm) was pretty easy, and very little fuss.
To me real scaling is where you're having to run a cluster since a single server is inadequate to handle the traffic, where you're having to implement or leverage various application caching schemes, etc...
This fascination with scaling is hazardous to the health of both the startup and engineering communities.
To recommend against rails based on the assumption that it'll scale badly in cases where it has to handle more than 100k views per day isn't really helpful.
Once you reach these values, chances are, you'll have team, budget and need for a custom solution anyways.
Now, I'm no rails developer and I never got to really like the framework. So if you ask me, I would find other issues that prevent me myself from using rails (many personal soft-facts - a matter of preference). The (supposed) inability to scale beyond 100k views/day isn't one I'd consider first
But remember that a lot of people who start with Rails are not sysadmins, and may have absolutely no idea how to scale anything. I'd bet they'd probably hit the same scaling trouble if they used anything.
If you listen to folks that have had to scale out to meet demand, you hear the same thing repeated: once you get beyond a certain number of connections, things like choice of language level out and you have other things to worry about. Default installs of WordPress don't scale either, because of database load. That doesn't necessarily mean that WordPress can't scale.
Like anything else, Rails can scale, but often times those deploying it just don't know how. I know I sure didn't when I started out. And every web project I've been on has had different scaling needs. Rails has, in my experience, been easier to scale out than the ASP or PHP apps I used to maintain.
Can you explain how Rails doesn't handle this? Because all of my (admittedly limited) experience says it handles it just fine.
The major issues with scaling was that Ruby in general is absolutely horrible in managing memory, and was constantly having to be restarted. We ended up replacing the app with one built on top of Java which instead of requiring 6 servers with load balancer in front of it, to just 2 servers, one for the front-end and one for the backend. Java served the needs much better, faster, and didn't require the same amount of administration to constantly make sure that everything is still running properly.
Could the same have been done with Rails? Maybe. Are we happier with the Java based solution, its stability and speed? Yes absolutely.
What Java framework did you use, out of curiosity?
Incidentally, I'd be curious to hear about anyone's experience with Scala/Lift - if it's actually as efficient as straight-up Java, and how quick it is to develop stuff with.
While rails may be quick to develop with and may be great for prototypes it is not something that is ready for the prime time. The cost to get up to speed in Java was negligible compared to the end result, in that we are now able to have less time spent trying to debug problems because of Ruby not functioning correctly or having to be restarted (we had several tasks that took some database crunching in which ruby would sometimes fall over, or just take up all of the available memory thereby starving other processes and eventually being killed by the oom killer leaving parts of our database in an inconsistent state).
Which is of course, to use the technical term, "bullshit" :-)
There are a lot of statements that you could make that would be fair, like "Java is more mature", or "we have a lot of Java expertise, so it was much easier for us to debug it" or "for our particular needs, Rails simply wasn't suitable", but to say it's "not ready for prime time" is to deny the reality that it is used extensively in "prime time".
Thats why millions of users are using hundreds of large scale web apps right now built on Rails and/or Ruby (ie: Github, Slideshare, Hulu, Justin.tv, Basecamp, Alice.com ...the list goes on and on http://rails100.pbworks.com/Alexa+Rankings).
Right...
Might want to do some homework before making such a statement. True Ruby has memory issues. Running Ruby enterprise edition by passenger helped us a ton. Typically memory issues have to do with poorly written ruby more than anything...which rails makes it easy to do....like Product.all.each type stuff ... stupid example
Regardless, I subscribe to the belief that scaling is a good problem to have.
who scales?
Its no wonder when DHH and 37 signal espouse no features philosophy, since implementing them is hard and ruby + rails dont help.
You would rarely find any other engineer worth his salt saying that inability to implement a highly requested feature is a virtue and not a failure.