"Why did Twitter ditch Rails?" comes up a lot recently. It's good to remember that this was in a completely different era.
@katafrakt what’s the current concurrency model of modern RoR?
@Amikke @katafrakt Processes plus threads. For most Rails apps that gives you about a 5x-6x multiplier on speed-for-RAM from what they were getting there.
Not perfect, but better. Can also use something where threads are basically as capable as full processes -- e.g. JRuby or TruffleRuby, which have no Global VM Lock. But that's a larger transition in lots of ways, and most shops can't/won't.
In theory at some point Ractors will change things even more. But that's far future, if it's happening. And at most it will only bring CRuby up to the concurrency performance of something GIL-less.
@codefolio @katafrakt the processes+threads honestly still sound like a major downgrade compared to actor models of things like Scala or the Erlang family (and it seems Ractors if they ever happen), where concurrency is intuitive to implement and a first-class element of the language, and all internal functionality is thread-safe (this part seems to not entirely be the case for Scala lol) and GIL-less by default.
Not enough to warrant abandoning Ruby like when it was single-threaded, mind you, but enough to make something like Elixir strongly preferred over it if you’re choosing the technology to start with.
@Amikke @katafrakt
Fair. Concurrency is *not* one of Ruby's strongest suits.
There are some attempts to adapt actor models to Ruby, including Ractors. But Ruby has always prioritised authoring and interface over efficiency. It's one reason we (Matz, particularly) doesn't much like threads.
The GVL, weirdly, gives some advantages we haven't been able to replicate without it -- roughly the same reason Python has had one so long.