Earlier quoted context omitted.
Web stuff tends to be embarrassingly parallel: http://en.wikipedia.org/wiki/Embarrassingly_parallel . Which means that it's extremely easy to make a framework that's reentrant: http://en.wikipedia.org/wiki/Reentrancy_(computing) . Reentrancy gives you thread-safety by default. Yeah, Ruby core data structures are not thread-safe. But that doesn't matter. You're not supposed to a lot of any data structures between requ…
> Maybe I'm just too familiar with Ruby and multithreading, but I don't understand why people have trouble with multithreaded Ruby. [...] In my opinion, the situation is not much different in Python, Java or C++. I think the problem is a mix of language features and culture. Ruby does not have a history good thread-safe practices, and the language has some extremely convenient features which are death for thread-safe…
Weeell, but this (class-level state) is true of virtually all non-functional environments though, right? -- including the otherwise excellent concurrency support within the JVM.
If someone's using class/global state in a contentious, multi-threaded environment, they...probably should not be developing on that particular problem.
As you pointed out, the fact of class-level state isn't so much an argument against Ruby per se. To me it's more of an argument in favor of stateless/functional programming where data contention is high -- which is somewhat besides the point in this conversation because we're talking about (mostly) "embarrassingly parallel" concerns where data tends to be siloed and contention is low.
>> if I knew I needed heavy multi-threading for memory efficiency and CPU utilization I might disqualify Ruby on cultural reasons alone
But...aren't these exactly the kind of problems that REE/Passenger, Unicorn and Puma (not to mention EventMachine and Rack) have been digging into for years now?
As much of a bad rap as Ruby tends to get when it comes to threading, the GIL and so forth, I think what gets lost in that conversation is the fact that many flavors of Ruby application server configurations are serving thousands and thousands of concurrent requests in production every second and doing a pretty good job of it. In certain contexts, Ruby handles concurrency and parallelism admirably well.
"Culture" is a relative question -- are we talking about the guys at Phusion, or Engine Yard, or Heroku, or someone like Evan Phoenix, or Yehuda? Is that Ruby culture? There's some heavy threading brain-power in that group, and they've left a pretty big footprint on the Ruby/Rails community.
Or are we talking about (no offense) journeyman web coders who generally don't have to solve threading/high-contention, CPU-intensive problems all the time? I'm honestly not sure that at this point the Ruby community is any worse off than other communities in that regard.
In 2013, the Ruby/Threading issue is starting to feel (to me) a bit like the "Java is slow" notion did in the early 2000s. Might be time to look at what Ruby is actually doing in production and rethink that idea.