News for hackers. Stuff that matters.
Re:Why we switched from Python to Go by steveklabnik on Wednesday October 18, 2017 @03:34PM (#15502198)
It's been a while, but I thought that MRI basically slept during IO and released the GIL so that other threads could do work. In that case, you'd still be handling more requests while the IO was performed. I could be wrong. This kind of thing: http://ablogaboutcode.com/2012/02/06/the-ruby-global-interpr...
Re:Why we switched from Python to Go by viraptor on Wednesday October 18, 2017 @04:01PM (#15502428)
You're right that it can do async io. But you compared a framework to a language. Rust has Tokio for async - Iron is just not using it.

It's similar with Ruby/RoR - yeah, they can do async. But not on their own. With unicorn server, you still get no threading and just a bunch of processes. With puma you can do threading (async cooperative really) - as long as you keep the configuration/code within the limits of what's allowed.

And due to the extra care needed whenever you do caching/storage things, I expect unicorn is still the king in RoR deployments. (GH uses that for example)

Re:Why we switched from Python to Go by tychver on Thursday October 19, 2017 @07:08AM (#15506909)
It's definitely preemptive rather than cooperative. Ruby/Puma is actually using one OS thread per Ruby thread, so when one hits a DB call and blocks on sync IO, it releases the GVL and another Ruby thread can proceed. There's a timer thread Ruby runs and pre-empts each thread to schedule them.
Re:Why we switched from Python to Go by steveklabnik on Wednesday October 18, 2017 @04:29PM (#15502698)
Yeah, I guess I moved to Puma long enough ago that I forgot about this. Good points, thank you.
Re:Why we switched from Python to Go by tychver on Thursday October 19, 2017 @05:08AM (#15506479)
Yeah, that's pretty much what happens. There's also non-blocking IO you can use with EventMachine but the DB drivers are a bit of an issue AFAIK.