Both Puma (https://github.com/puma/puma, a popular server these days) and Passenger Enterprise (paid) provide multithreaded web support. Also on the background jobs side, Sidekiq https://sidekiq.org is very popular.

Those are both solid choices for servers. However neither of them have a scalability model suitable for HTTP/2 or WebSockets. That's something I wanted to try and address.

And thank you for addressing it, Samuel!

I converted the streaming and Autopark clients in the Tesla API gem from EM to Async and has been great: https://github.com/timdorr/tesla-api/blob/master/lib/tesla_a...

No more globals, which makes it much safer to use inside of threaded job runners like Sidekiq.

It would be awesome to talk about your work in a blog post, do you think you can reach out to me to explain your work in more detail?

I used EventMachine a lot about 8-10 years ago. I'm excited to see Ruby getting some concurrency love again. What are the goals and improvements of your underlying design in general, and especially those that make HTTP2 and WebSockets work?

Light weight event driven tasks are very important.

I outline some of the key improvements in this talk:

https://www.youtube.com/watch?v=Dtn9Uudw4Mo

Concurrency is one of those core features which is hard to add after-the-fact, and so the initial design strongly determines the course of the language's life. It requires re-opening such fundamentals as what does it mean to call a function, or assign to a variable.

"Nobody is using Ruby for multithreading" is both cause and effect.

That's why I'm not terribly optimistic about projects like this (or the proposed Swift 6). That's not how these things work. Can you imagine a language which features good concurrency support today (like Erlang or Clojure) having been launched without it, and then announcing 5 (or 25) years later "We're going to address concurrency now"?

Completely agree with you and to me that's why it's an exciting challenge. I'm not expecting to solve every problem, but I'm trying to carve out a solution which I think works for these legacy issues. Even if we didn't have a solution for the last 25 years, no harm in adding one now! :)

Not a common use case, but a GUI with background processing is terrible without parallelization.

Even if the background process is I/O intensive (which is supposed to be most of the time waiting, therefore freeing the CPU for the foreground process), it doesn't mean it won't end up still blocking (I've experienced this with filesystem operations).

Actually, I was looking at how audio loops work, and it seems like the low context switching overhead of fibers could be really great for stacks of effects and filters. Because the overhead is very small and predictable, and the ergonomics of fibers is easier to deal with, it could make for a really nice interface.