I am biased, but I disagree. I've reviewed projects where teams have attempted to compensate for the performance problems of Rails and Ruby by scaling (dramatically) horizontally. Projects that are simple in functionality but have dozens of servers and complex overall application architecture and topology. Projects where the big guns of scalability had to be brought to the battlefield very prematurely.

Today, I argue for quite the opposite approach. Select a high-performance platform that is workable for your team and enjoy the luxury afforded by raising your performance ceiling. Rather than your platform and framework creating an unreasonably low and frustrating performance ceiling—wherein you will find yourself fussing with performance tuning and complex system architecture way earlier than you should, use high-performance infrastructure and defer tuning your application for a long time, if not indefinitely.

Performance is an objective measure, but what performance means to you is potentially subjective. For my part, high performance means peace of mind. I can write my application more quickly, using brute-force algorithms and other quick implementation tactics. I can tune my application later, if and when the need arises.

But if my platform is what causes my performance pain, tuning my application is a futile exercise. I am forced to increase my system's architecture and add more servers, load balancers, messages queues, job workers, all manner of things that make my architecture sound awesome to a programmer but do nothing to improve a user experience where pages are still taking 500ms of server side processing to execute trivial operations.

Yes, with enough effort, essentially any platform and framework could service any application's performance needs. Facebook is famously built on PHP, which is not a fast platform (modest in raw form; slow when encumbered with a framework). Facebook has invested untold scores of dollars into tuning. This is what I feel is important to those of us building just average apps: you probably won't have the money and developer bandwidth to actually tune your platform, as Facebook has done with PHP. So you'll scale horizontally and add a lot of architectural complexity and cost. This might more or less work, and you may be successful in spite of the unnecessary complexity. But my opinion is that it's easier and more comfortable to select for high-performance at the start and just defer that complexity; defer optimization.

I find the upsides of Ruby are subjective. "Programmer happiness" is obviously a subjective matter. I personally am considerably happier on a high-performance platform, especially one that is easy to work with. I am not alone.

Thank you to Ruby and Rails for pushing for a lot of great ideas we enjoy on other platforms today. But its performance has never been good enough for my tastes and that remains the case in 2016.