fibur

then I couldn't change my concurrency model. For example, if I used EventMachine with its callbacks approach, it would be much harder to switch back to Rubinius with threading. In a nutshell, Sinatra::Synchrony is just a tool, it should probably not be your first choice, and you shouldn't use it unless you understand the problem domain. So because of this, I have provided a section of articles to help people understand this (http://kyledrake.net/sinatra-synchrony/#further-reading), and I also provided a section describing how Ruby's current IO subsystem works (it needs to be updated a bit): http://kyledrake.net/sinatra-synchrony/#caveats The reason I dropped this on Hacker News yesterday was because I was getting sick of people writing about how they were dumping Ruby or Python or something else for Node.JS to get "scalability" when in fact not only is blocking IO not a problem in Ruby itself, but you can also use a Reactor pattern in Ruby, just like Node.js does. I thought it was important that people could see how easily you could integrate a reactor pattern without having to completely rewrite your code base. I think the problem this is highlighting is that people are simply not informed on what's going on here. In other words it is a documentation failure. This is not helped by the fact that Thin uses EventMachine, which turns off threads (hence killing the internal non-blocking code), and Thin is default on many different things (Sinatra, Heroku, Rack, etc). Supposedly Thin now has a "threaded" mode which Sinatra 1.3 uses, but I don't know if that is still based on EventMachine or not. Point is, we shouldn't be using EventMachine by default on web servers at all, it should be something you explicitly turn on and understand. I will be writing a blog post this week to discuss this, since apparently there's a lot of confusion out there. I'm going to also provide our deploy strategy for non-EM web apps. Our main site does not use Sinatra::Synchrony. It uses Rainbows! with a thread pool and it works beautifully, we can handle thousands of hits per second on our site without a problem. Anybody that tells you Ruby doesn't scale is lying to you. Ruby scales incredibly well for a wide range of problem domains. The one thing I want to say though, is that Sinatra::Synchrony does provide a valuable purpose: It is a power tool designed to give you an option for improving raw performance by doing something that isn't necessarily the best thing to do, but I've occasionally needed that capability, so I wanted to share that capability with the community. TLDR: Fuck this shit bro get a coors lite out of the fridge and use Node.JS it ROFLscales bro. Fibur is so tight that only a Hacker could have wrote it, but there were some problems I found: https://github.com/tenderlove/fibur/issues