4 ms·
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 r
by 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 agoEvery 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 agoThreads 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.)