Q:

The need to write code in another language for rails production app?

I have seen several reference to developers having to write certain parts (background processing, perf. intensive tasks) of their rails apps in a language other than Ruby (Java or C) once user load increased (it seems that Twitter is an ex. of this). It is possible that these were issues that appeared mostly during the Rails 1.0 -2.0 era. However, I wanted to confirm with devs who run real production applications if this indeed still is the case.

A:

In my experience there is rarely, if ever, a need to write the server-side parts of your Rails application in a language, other than Ruby.
The issues suffered by companies like Twitter, are well outside the realm of what most web applications will ever have to deal with, and so for the sake of this discussion, they should be ruled out. Twitter is an extreme outlier.
However, in most non-trivial Rails apps, there is usually a requirement for background job queuing and processing, although these jobs are also usually written in Ruby.
A good rule to adhere to is that you should never make a user wait, and return responses to HTTP requests immediately, without unnecessarily tying up (Ruby-backed) request processors. For example, if a large image is uploaded and it requires a number of intensive transformations - this should be done asynchronously and offline. This is also true of other web application frameworks and languages, regardless of their performance.
If you need more performance for background jobs, you can simply scale out the number of worker processes that are processing jobs. This is also true for serving Rails requests - you can for example add more Unicorn worker processes to process more requests.
Whilst Ruby is indeed significantly slower than C or a warmed up JVM, it is usually "fast enough".
If you are using MRI Ruby, then you should be using Ruby 1.9.3, which is at least twice as fast as the 1.8.x series, and has slightly improved garbage collection. JRuby also performs well, and gets significantly more performant with every release.
Finally, modern Rails apps offload a great deal more processing to the client, and typically contain more JavaScript / CoffeeScript than they used to. They frequently use more partial AJAX updates to the View, which results in less time spent rendering by the Rails stack, and smaller, lighter database queries with significantly less server-side Ruby processing, than would have been seen, say, 4 years ago.
The biggest risks to your application are not performance-related, and will usually be rapidly changing requirements and the need to deliver on time and on budget. This is true of any technology choice, although Rails is known to help mitigate in these areas. I am writing this from the position of a developer that has used many frameworks and languages over the years, which include measurably faster languages and stacks, i.e. PHP, C# / ASP.NET MVC.

