Also interesting to see Mypyc, Pyre related AOT compiler (forget the name), and now this.
Great to see! We’d gladly compile our code in CI if it meant better perf (already do for the UI stuff)
Instead, I/O problems are frequently a language-agnostic set of problems, like:
- Oh jeez, I'm making a database roundtrip 2x more frequently than I'd like to! Maybe I should change my application to batch the database requests.
- Oh jeez, I'm running on cheaper EC2 instances without SSDs, maybe I should upgrade!
etc.
Granted, there's been a lot of interesting work done on Ruby concurrency lately, but it's far from a solved problem at the language level.
(background: former Shopify EM)
I'm currently working on Polyphony [0], a Ruby gem for writing highly-concurrent Ruby apps. It uses Ruby fibers under the hood, and does I/O using io_uring (on Linux, there is also a libev-based backend).
> It uses Ruby fibers under the hood,
I'm sure you are aware of ioquatix's work on Async/Falcon etc, how do you see your project differing from his work? And why hasn't anything changed in the Ruby server space - it's all processes and threads afaik.