3 ms·

Sorry, but I have to dismiss this as Obie protecting his economic interests as an owner of a Rails consultancy. I can only guess that he sees negative Ruby cov

Sorry, but I have to dismiss this as Obie protecting his economic interests as an owner of a Rails consultancy. I can only guess that he sees negative Ruby coverage like this as a threat to new Ruby development, and thus the future of his consultancy. With few exceptions, Ruby applications running on MRI will be wholly unsuited to high throughput environments. This is true regardless of how good your Ruby code is. Saying that using Object#kind_of? is bad Ruby coding may be true but it's mostly orthogonal to the speed of the code. Even the most aesthetically pleasing, extensible, and clean Ruby code will be slow. After a certain threshold of requests per second the bottleneck will almost always become Ruby. After all, it might not even matter how aggressive your caching strategy is if it can take upwards of 50ms to even talk to your cache. MRI Ruby's IO subsystem and its threading model absolutely hamstring its suitability for even IO bound applications. The good news is that Ruby will improve in the future. For better or worse, Engine Yard hitched its wagon to the 1.8.x generation of Ruby. Engine Yard's customers will be using the 1.8.x series of interpreters for quite some time to come. And Engine Yard has the engineering know how and an economic interest on improving that generation of Ruby. But in the meantime those of us building applications that need to make efficient use of a given set of hardware are left with a choice. Do we fight with our platform tooth and nail to try and wring even an acceptable amount throughput out of it? Or do we change our platform to best suit the problems in front of us?

tdavis 18y ago
Sorry, but I have to dismiss this as Obie protecting his economic interests as an owner of a Rails consultancy This was my exact thought. After reading his claims to Alex's "agenda", I looked at the sidebar and saw that he's written four (obnoxiously-covered) Ruby books. Who really has the agenda here? Near as I can tell, Alex's entire argument was "Twitter is really big and ugly; we need a stricter type system; Ruby doesn't have one." That seems perfectly legitimate to me.
- ejs 18y ago
  He has only written one of those books (The Rails Way) the others are just books in the series. I don't think he choose the covers either. He also states at the end: "Have I been guilty of this stuff in my own past as a Rails advocate with a strong agenda? Yeah, probably so. Which is why I know it when I see it. :)"
- jraines 18y ago
  Also, as Alex himself alluded in his original piece, why would someone who presumably has a stake in a company that shrugs off half-billion dollar acquisition offers be trying anything devious to promote a technical book?
  - jeremymcanally 18y ago
    Fun? Personal brand? I mean, I make more than enough to get by on but I still promote my book every change I get. :)
bjclark 18y ago
You dismiss anyone who's job applies to the topic at hand? Shouldn't you dismiss Alex because he's writing a book for O'Reilly on Scala? Should the only people allowed to discuss this be the Erlang people? Just asking because I'd bet they would say that Kestrel is a crappy version of RabbitMQ.
- moonpolysoft 18y ago
  Please try to pay closer attention. That was my conclusion after reading what he said. He claims good Ruby code would have helped Twitter. My experience and apparently the experience of Alex and his team prove otherwise. And as for Kestrel, you can call it a crappy version of X all you care to, and it may be depending upon how requirements for X and Kestrel differ. One thing to keep in mind is that essentially the Twitter engineers are doing the software engineering equivalent of rebuilding a jet aircraft in midflight. Part of the point of having a modular architecture is to try and set up API's that act as firebreaks for intra-module changes. So if you need to switch out your message queue for performance reasons, rewriting a brand new one that conforms to the API the rest of your system expects might be the best solution at the moment. Otherwise by breaking compatibility you can set off cascading changes which require rewrites all across the system.
  - jshen 18y ago
    I didn't realize that anecdotes proved things. You should pay closer attention to the things you say.
jasonwatkinspdx 18y ago
I don't believe Engine Yard has hitched it's wagon. Quite the opposite considering they fund a great deal of work on the Rubinius ruby implementation effort. Generalizations like "ruby falls down at high throughput" are fun to echo but a poor basis for planning architecture. The constraints of the tools you're using matters, but so does the overall pattern of how you're applying them. Efficiency is a property of languages. Stability and Scalability are properties of architectures. Design is the process of fitting one to the other, and requires real actual thought, work and measurement, not just repeating chestnuts.
- ilkhd2 18y ago
  Not necessarily. Sometimes, the very structure (syntactic I mean) of language makes ceratin kinds of abstractions (behavior abtractions as well) veryhard to implement, which is effectively same as having no way to express them. I mean, for example - there is no way, absolutely no way to write Lapack benchmark in Ruby to be as fast as C one in reasonable amount of time (you can always emit machine code and run afterwards, but that is cheating). Or less controversial example: Java VM has no tail recursion optimisation, and for example Clojure does not have either. That means you have no way to use certain class of programmin techniques with it, As a conclusion: languages largely prescribe the way to implement architecture with them.
  - ilkhd2 18y ago
    By the way for me it is also important that the particular Language has non-gpl translators.That is also can contribute to the choice of the language for particular task, and consequently the final architecture.
  - jasonwatkinspdx 18y ago
    I think we're in agreement without quite realizing it. These are examples of efficiency, not scalability. This distinction isn't quite binary, and Ahmdal's law is a good approximation. But for the discussion at hand we can generally ignore the serially dependent portion of the workload. Also, I'm speaking of systems architecture, not program architecture, so whether tail calls are interpreted or compiled doesn't really apply. To make my point more clear: I'm absolutely certain you could write twitter in pure ruby, even at it's current traffic level. It's also likely this wouldn't make sense, as the economics would be wrong. But the economics would be due to efficiency * hardware costs as compared to programmer staff costs, not any limitation of scalability. I would grant you that there are a few exceptional cases where the language really does constrain the system's architecture (non turing languages and jailed languages with limited connectivity options) but those are never the languages being discussed in "does it scale" debates.

tdavis 18y ago

Sorry, but I have to dismiss this as Obie protecting his economic interests as an owner of a Rails consultancy This was my exact thought. After reading his claims to Alex's "agenda", I looked at the sidebar and saw that he's written four (obnoxiously-covered) Ruby books. Who really has the agenda here? Near as I can tell, Alex's entire argument was "Twitter is really big and ugly; we need a stricter type system; Ruby doesn't have one." That seems perfectly legitimate to me.

ejs 18y ago
He has only written one of those books (The Rails Way) the others are just books in the series. I don't think he choose the covers either. He also states at the end: "Have I been guilty of this stuff in my own past as a Rails advocate with a strong agenda? Yeah, probably so. Which is why I know it when I see it. :)"
jraines 18y ago
Also, as Alex himself alluded in his original piece, why would someone who presumably has a stake in a company that shrugs off half-billion dollar acquisition offers be trying anything devious to promote a technical book?
- jeremymcanally 18y ago
  Fun? Personal brand? I mean, I make more than enough to get by on but I still promote my book every change I get. :)

bjclark 18y ago

You dismiss anyone who's job applies to the topic at hand? Shouldn't you dismiss Alex because he's writing a book for O'Reilly on Scala? Should the only people allowed to discuss this be the Erlang people? Just asking because I'd bet they would say that Kestrel is a crappy version of RabbitMQ.

moonpolysoft 18y ago
Please try to pay closer attention. That was my conclusion after reading what he said. He claims good Ruby code would have helped Twitter. My experience and apparently the experience of Alex and his team prove otherwise. And as for Kestrel, you can call it a crappy version of X all you care to, and it may be depending upon how requirements for X and Kestrel differ. One thing to keep in mind is that essentially the Twitter engineers are doing the software engineering equivalent of rebuilding a jet aircraft in midflight. Part of the point of having a modular architecture is to try and set up API's that act as firebreaks for intra-module changes. So if you need to switch out your message queue for performance reasons, rewriting a brand new one that conforms to the API the rest of your system expects might be the best solution at the moment. Otherwise by breaking compatibility you can set off cascading changes which require rewrites all across the system.
- jshen 18y ago
  I didn't realize that anecdotes proved things. You should pay closer attention to the things you say.

jasonwatkinspdx 18y ago

I don't believe Engine Yard has hitched it's wagon. Quite the opposite considering they fund a great deal of work on the Rubinius ruby implementation effort. Generalizations like "ruby falls down at high throughput" are fun to echo but a poor basis for planning architecture. The constraints of the tools you're using matters, but so does the overall pattern of how you're applying them. Efficiency is a property of languages. Stability and Scalability are properties of architectures. Design is the process of fitting one to the other, and requires real actual thought, work and measurement, not just repeating chestnuts.

ilkhd2 18y ago
Not necessarily. Sometimes, the very structure (syntactic I mean) of language makes ceratin kinds of abstractions (behavior abtractions as well) veryhard to implement, which is effectively same as having no way to express them. I mean, for example - there is no way, absolutely no way to write Lapack benchmark in Ruby to be as fast as C one in reasonable amount of time (you can always emit machine code and run afterwards, but that is cheating). Or less controversial example: Java VM has no tail recursion optimisation, and for example Clojure does not have either. That means you have no way to use certain class of programmin techniques with it, As a conclusion: languages largely prescribe the way to implement architecture with them.
- ilkhd2 18y ago
  By the way for me it is also important that the particular Language has non-gpl translators.That is also can contribute to the choice of the language for particular task, and consequently the final architecture.
- jasonwatkinspdx 18y ago
  I think we're in agreement without quite realizing it. These are examples of efficiency, not scalability. This distinction isn't quite binary, and Ahmdal's law is a good approximation. But for the discussion at hand we can generally ignore the serially dependent portion of the workload. Also, I'm speaking of systems architecture, not program architecture, so whether tail calls are interpreted or compiled doesn't really apply. To make my point more clear: I'm absolutely certain you could write twitter in pure ruby, even at it's current traffic level. It's also likely this wouldn't make sense, as the economics would be wrong. But the economics would be due to efficiency * hardware costs as compared to programmer staff costs, not any limitation of scalability. I would grant you that there are a few exceptional cases where the language really does constrain the system's architecture (non turing languages and jailed languages with limited connectivity options) but those are never the languages being discussed in "does it scale" debates.