Making scalable and highly available services has nothing to do with the programming language, at least by itself. This area would generally be the *last* place I'd look, not the first thing I'd bash. There *may* be implementation issues with a language, but its impossible to determine based on what I have heard so far how many, if any, of the issues Twitter is having have anything to do with Ruby or Rails.
For example, the 500 errors we saw yesterday were caused by the need to restore a crashed database instance. This doesn't sound like a Ruby or Rails issue to me.
Architecture and designing services for scaling and availability is about physics. The discipline has a lot more to do with things like how you go about identifying single points of failure, looking for bottlenecks, and tying to understand the implications of maintaining state than anything to do with Ruby or the Rails framework.
Dan Keldsen
· 1 year ago
The "does it scale?" question is similar to the "what's the ROI?" question.
Both are what ask do when they want to just be able to shoot a project down. Funny how their own pet projects don't get this sort of nonsensical scrutiny.
It's not that the questions are unimportant, but they focus on such a narrow aspect and leave truly important discussions and strategy stuck in a corner.
All Comments
Making scalable and highly available services has nothing to do with the programming language, at least by itself. This area would generally be the *last* place I'd look, not the first thing I'd bash. There *may* be implementation issues with a language, but its impossible to determine based on what I have heard so far how many, if any, of the issues Twitter is having have anything to do with Ruby or Rails.
For example, the 500 errors we saw yesterday were caused by the need to restore a crashed database instance. This doesn't sound like a Ruby or Rails issue to me.
Architecture and designing services for scaling and availability is about physics. The discipline has a lot more to do with things like how you go about identifying single points of failure, looking for bottlenecks, and tying to understand the implications of maintaining state than anything to do with Ruby or the Rails framework.
Both are what ask do when they want to just be able to shoot a project down. Funny how their own pet projects don't get this sort of nonsensical scrutiny.
It's not that the questions are unimportant, but they focus on such a narrow aspect and leave truly important discussions and strategy stuck in a corner.