4 ms·

This argument falls flat to me. All of Ruby's competitors ran on similar servers 13 years ago as well (except for a few that didn't exist yet). All of them hav

This argument falls flat to me. All of Ruby's competitors ran on similar servers 13 years ago as well (except for a few that didn't exist yet). All of them have optimized and improved their speed since then. In 2003, it was expected that web pages have a bit of a delay before loading. In 2016, it is not. Ruby has not yet adapted.

mmanfrin 10y ago
Are you suggesting that Ruby has not improved its speed? Are you suggesting that Ruby is too slow for the web?
- Practicality 10y ago
  No. His argument is "It was fast enough in 2003 and it's gotten faster, so Ruby is fast enough now." He repeats the "it was fast enough in 2003," 3 times in the article. I disagree with the premise that fast enough in 2003 is fast enough now. Adding a vague "it's gotten faster" is not sufficient to mean that it's fast enough for 2016. It may or may not have improved enough, but either way this argument does not prove that it has.
  - mmanfrin 10y ago
    The point DHH is trying to make is not that 'Ruby is fast', but that 'Ruby is fast enough' for what people generally need. If you're building some whatsapp-esque messaging platform, then yeah: ruby is not fast enough; but for a majority of the uses that Ruby is used for (building web applications) it is indeed fast enough to build enterprise-level applications.
  - PeterisP 10y ago
    Something that was fast enough in 2003 is sufficient to say that it's fast enough to 2016 - even if nothing has improved, it's going to be an order of magnitude faster simply because of hardware improvements. There are some technologies that were impractically slow in 2003 but have become 'fast enough' in 2016 either by improvements of tech or just by having more cpu/ram/gpu power - but not the other way around.
carsongross 10y ago
A typical request to our rails app will be served in under 100ms, with the majority of that time being data access. Even the fastest Go app is one bad query away from a horrible response time. CPU in the web layer is not the bounding issue for most web apps.
sametmax 10y ago
Most of the pages I visit now load slower than in 2003. The server language has nothing to do with it, and is not the bottleneck in 99% of the cases.
kyledrake 10y ago
I'm really not subscribing to your argument that every other language got faster and ruby didn't. Ruby performance has increased significantly since 2003, and ruby has had concurrent IO using threads since 1.9. Python shares the GIL problem, and Node doesn't even have threads (have fun debugging events!), so you're not going to add much water to the argument in that department. Additionally, computers got much faster and have many more cores, allowing for additional process concurrency. This is an argument for me to move to higher level, more abstract languages, not to race back to lower level languages because "they're fast". If anything, ruby/js/python aren't high level enough and could be slower but more productive. I'd choose that over raw performance for the vast majority of my needs. Additionally, Rails benchmarks might show ~100 hits per second (that's 8,640,000 hits per day per process, do you actually get that much traffic?), but I can get thousands of hits per second running Sinatra. I still think Rails is plenty fast, but it's silly to blame a language for a framework. Ruby has for years been a victim of FUD, opinions on it's performance that seem to have been derived from fuzzy stereotypes rather than actual information. I think that's what the author is frustrated about, because that's the one thing I'm pretty frustrated about too. I'll be the first person to abandon ruby when a better language comes out for my needs, but I've still never seen it.
- jerluc 10y ago
  Every language that supports threads has "concurrent IO". That's what threads/processes are for. However, threads will never help you in an IO-bound system (unless you own some kind of thousand-core CPU with an equal number of OS threads). Threads will simply block at the first waiting IO call until you eventually run out of threads. Node.js from the beginning was built for non-blocking IO, as are several Python frameworks (e.g. Twisted, or more recently, Tornado), thus the need for more than one thread of execution was typically unnecessary (again, provided the bottleneck was IO).
  - otterley 10y ago
    Threads can absolutely help you in an I/O-bound system where concurrency is possible and desirable - specifically, in a RAID environment. (You can't max out RAID throughput with a single thread - try it.)

mmanfrin 10y ago

Are you suggesting that Ruby has not improved its speed? Are you suggesting that Ruby is too slow for the web?

Practicality 10y ago
No. His argument is "It was fast enough in 2003 and it's gotten faster, so Ruby is fast enough now." He repeats the "it was fast enough in 2003," 3 times in the article. I disagree with the premise that fast enough in 2003 is fast enough now. Adding a vague "it's gotten faster" is not sufficient to mean that it's fast enough for 2016. It may or may not have improved enough, but either way this argument does not prove that it has.
- mmanfrin 10y ago
  The point DHH is trying to make is not that 'Ruby is fast', but that 'Ruby is fast enough' for what people generally need. If you're building some whatsapp-esque messaging platform, then yeah: ruby is not fast enough; but for a majority of the uses that Ruby is used for (building web applications) it is indeed fast enough to build enterprise-level applications.
- PeterisP 10y ago
  Something that was fast enough in 2003 is sufficient to say that it's fast enough to 2016 - even if nothing has improved, it's going to be an order of magnitude faster simply because of hardware improvements. There are some technologies that were impractically slow in 2003 but have become 'fast enough' in 2016 either by improvements of tech or just by having more cpu/ram/gpu power - but not the other way around.

carsongross 10y ago

A typical request to our rails app will be served in under 100ms, with the majority of that time being data access. Even the fastest Go app is one bad query away from a horrible response time. CPU in the web layer is not the bounding issue for most web apps.

sametmax 10y ago

Most of the pages I visit now load slower than in 2003. The server language has nothing to do with it, and is not the bottleneck in 99% of the cases.

kyledrake 10y ago

I'm really not subscribing to your argument that every other language got faster and ruby didn't. Ruby performance has increased significantly since 2003, and ruby has had concurrent IO using threads since 1.9. Python shares the GIL problem, and Node doesn't even have threads (have fun debugging events!), so you're not going to add much water to the argument in that department. Additionally, computers got much faster and have many more cores, allowing for additional process concurrency. This is an argument for me to move to higher level, more abstract languages, not to race back to lower level languages because "they're fast". If anything, ruby/js/python aren't high level enough and could be slower but more productive. I'd choose that over raw performance for the vast majority of my needs. Additionally, Rails benchmarks might show ~100 hits per second (that's 8,640,000 hits per day per process, do you actually get that much traffic?), but I can get thousands of hits per second running Sinatra. I still think Rails is plenty fast, but it's silly to blame a language for a framework. Ruby has for years been a victim of FUD, opinions on it's performance that seem to have been derived from fuzzy stereotypes rather than actual information. I think that's what the author is frustrated about, because that's the one thing I'm pretty frustrated about too. I'll be the first person to abandon ruby when a better language comes out for my needs, but I've still never seen it.

jerluc 10y ago
Every language that supports threads has "concurrent IO". That's what threads/processes are for. However, threads will never help you in an IO-bound system (unless you own some kind of thousand-core CPU with an equal number of OS threads). Threads will simply block at the first waiting IO call until you eventually run out of threads. Node.js from the beginning was built for non-blocking IO, as are several Python frameworks (e.g. Twisted, or more recently, Tornado), thus the need for more than one thread of execution was typically unnecessary (again, provided the bottleneck was IO).
- otterley 10y ago
  Threads can absolutely help you in an I/O-bound system where concurrency is possible and desirable - specifically, in a RAID environment. (You can't max out RAID throughput with a single thread - try it.)