This is a good example of why anything related with threading makes me nervous when using Ruby. When a language is mutable and thread-unsafe by default, keeping the whole stack sane at all times seems prohibitively arduous. One cannot code-review a whole ecosystem.
I believe that this could be addressed with an architecture that favored single-threaded processes that can handle a single request at a time. Said processes would be numerous, have a (best-effort) low memory footprint, and be pooled under some master process written in a concurrent/performant manner.
The result wouldn't be necessarily pretty or resource-efficient (especially in terms of RAM), but it also can be seen as a consequence of Ruby's requirements for safety.
An org like GH almost certainly can afford using more/beefier servers it it means that entire classes of bugs will go away.
To be fair to Ruby, most languages are largely mutable and without any strong thread-safety guarantees. Does that make it okay? No, but it’s far from a Ruby-specific problem.
> I believe that this could be addressed with an architecture that favored single-threaded processes that can handle a single request at a time.
Unicorn (the application web server GitHub is using) does follow this model. GitHub added their own additional thread within that process that broke that design in an unforeseen way.
I believe that this could be addressed with an architecture that favored single-threaded processes that can handle a single request at a time. Said processes would be numerous, have a (best-effort) low memory footprint, and be pooled under some master process written in a concurrent/performant manner.
The result wouldn't be necessarily pretty or resource-efficient (especially in terms of RAM), but it also can be seen as a consequence of Ruby's requirements for safety.
An org like GH almost certainly can afford using more/beefier servers it it means that entire classes of bugs will go away.