14 ms·

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 (dramati

by bhauer 10y ago

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.

pbreit 10y ago
Except that only a small percentage of projects need to scale. So you're generally much better off trading scalability for productivity.
- bhauer 10y ago
  That's precisely the point: a low-performance platform causes you to need to scale and bring out complex system architecture way earlier in your project's lifetime. Systems that would be just fine on a single cheap server using high-performance software find themselves ramping up complexity with only very modest usage. I'd prefer to avoid the need to scale to deal with a few hundred concurrent users. I'd prefer to imagine my CPU yawning and asking for more. You may be speaking of very low-traffic systems, and I will agree that with such a scenario, any technology could suffice. But in 2016, we programmers enjoy a lot of options for building web applications and services, including many high-performance platforms that are a joy to work with. Putting aside subjective matters such as existing preferences and experience, if you've got a new project and an open mind, why bother with low-performance when you can have high-performance and ultra-fast response to user requests? To be clear, I'm not saying existing preferences and experience are unimportant. But if you find yourself entertaining the option of using something new, I recommend factoring high-performance into the selection process to enjoy the peace of mind that it brings.
spinlock 10y ago
> 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. This is funny. The only think I like about writing VBA plugins for Excel is that I get to put my algorithms hat on and go for the optimal solution. I remember bringing one implementation from O(n^2) to O(nlgn) and being blown away by how much better the performance was.
dasil003 10y ago
I've been doing Rails now for over a decade (!) and in some sense I agree with DHH that Ruby is good enough. However I think it's also unavoidable that the Ruby language is designed in such a way that there is a performance ceiling that will be impossible to break through, and that we will increasingly feel that pain of that ceiling as applications get more complex. I still love Ruby, but there is a lot of interesting developments that are catching my eye just as Rails did so many years ago. It's important to remember what the web development landscape was like in 2004. PHP, Perl, ASP and Java are all weak languages which I would never choose over Ruby. These days things are condierably different. While I have no great love for Node, there are clear benefits to isomorphic client/server code, and going async-first across the board. Similarly whether it's Go, Rust, Elixir, Clojure or Haskell, there is significant community traction in languages that have order-of-magnitude better performance characteristics, and solve problems of both parallelism and type safety which pay huge dividends in performance and maintainability over time. I still think Rails is hard to beat for rapid prototyping, and I'm not in a rush to jump ship, but I think DHH is kind of sticking his head in the sand here. Once upon a time it made a lot of sense to pay Ruby's performance tax in exchange for the power and expressiveness of the language, these days I think we're seeing the ascendancy of languages that show you can still have great expressiveness while sacrificing much less in terms of performance, parallelism, and safety.

by bhauer 10y ago

pbreit 10y ago

Except that only a small percentage of projects need to scale. So you're generally much better off trading scalability for productivity.

bhauer 10y ago
That's precisely the point: a low-performance platform causes you to need to scale and bring out complex system architecture way earlier in your project's lifetime. Systems that would be just fine on a single cheap server using high-performance software find themselves ramping up complexity with only very modest usage. I'd prefer to avoid the need to scale to deal with a few hundred concurrent users. I'd prefer to imagine my CPU yawning and asking for more. You may be speaking of very low-traffic systems, and I will agree that with such a scenario, any technology could suffice. But in 2016, we programmers enjoy a lot of options for building web applications and services, including many high-performance platforms that are a joy to work with. Putting aside subjective matters such as existing preferences and experience, if you've got a new project and an open mind, why bother with low-performance when you can have high-performance and ultra-fast response to user requests? To be clear, I'm not saying existing preferences and experience are unimportant. But if you find yourself entertaining the option of using something new, I recommend factoring high-performance into the selection process to enjoy the peace of mind that it brings.

spinlock 10y ago

> 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. This is funny. The only think I like about writing VBA plugins for Excel is that I get to put my algorithms hat on and go for the optimal solution. I remember bringing one implementation from O(n^2) to O(nlgn) and being blown away by how much better the performance was.

dasil003 10y ago

I've been doing Rails now for over a decade (!) and in some sense I agree with DHH that Ruby is good enough. However I think it's also unavoidable that the Ruby language is designed in such a way that there is a performance ceiling that will be impossible to break through, and that we will increasingly feel that pain of that ceiling as applications get more complex. I still love Ruby, but there is a lot of interesting developments that are catching my eye just as Rails did so many years ago. It's important to remember what the web development landscape was like in 2004. PHP, Perl, ASP and Java are all weak languages which I would never choose over Ruby. These days things are condierably different. While I have no great love for Node, there are clear benefits to isomorphic client/server code, and going async-first across the board. Similarly whether it's Go, Rust, Elixir, Clojure or Haskell, there is significant community traction in languages that have order-of-magnitude better performance characteristics, and solve problems of both parallelism and type safety which pay huge dividends in performance and maintainability over time. I still think Rails is hard to beat for rapid prototyping, and I'm not in a rush to jump ship, but I think DHH is kind of sticking his head in the sand here. Once upon a time it made a lot of sense to pay Ruby's performance tax in exchange for the power and expressiveness of the language, these days I think we're seeing the ascendancy of languages that show you can still have great expressiveness while sacrificing much less in terms of performance, parallelism, and safety.