Async Ruby VS Polyphony

The Async gem is the natural successor, It's actively maintained, and allows you write synchronous code is if it wasn't non-blocking, and most libraries don't need any special support for Async (exceptions are gems with C extensions that do I/O and DB libraries with connection pooling that would otherwise be thread-based).

https://github.com/socketry/async uses coroutines and I think in general it’s been a great model with very few downsides in practice.

There's async I/O. Here's a library that leans on Ruby 3's fiber scheduler.

Hey folks, wanted to show this off and get feedback. Still early/experimental but there are quite a few concepts I'm excited about here. This project came about while writing a program in Go and loving its approach to concurrency. Being a long-time Rubyist I immediately started to think about what similar concepts might look like in Ruby.

I set out with two main design constraints:

1. Lightweight: I didn't want routines to be backed by fibers or threads. Having been involved some in the async project (https://github.com/socketry/async), I had some experience using fibers for concurrency but was curious if they could be avoided.

2. Explicitness: Routine behavior must be written to describe exactly how it is to behave. I always felt like concurrent code was hard to fully understand because of the indirection involved. On the spectrum between tedium and magical I wanted to err more on the side of tedium with Goru.

Goru routines are just blocks that are called once for every tick of the reactor. It is up to the developer to implement behavior in terms of a state machine, where on each tick the routine takes some action and then updates the state of the routine for the next tick. This fulfills both design constraints:

1. Because routines are just blocks, they weigh in at about ~345 bytes of memory overhead.

2. Routine behavior is explicit because it is written as a state machine inside the block.

Couple more features worth noting:

* Goru includes channels for buffered reading/writing (similar to channels in Go).

* Goru ships with primitives for non-blocking IO to easily build things like http servers.

Curious your thoughts!

For those who are interested here is the question.

Welcome! Ruby isn't exactly "dying", but the hype/popularity is definitely fading. This is primarily because Ruby is no longer "new", most of Ruby's popularity came from Rails, and now Rails is no longer the "new hotness". However, Ruby still has lots of awesome features and lots of awesome other libraries and frameworks, such as the new fancy irb gem that uses reline, nokogiri, chunky_png, the async gems, Dragon Ruby, SciRuby, Ronin, and the new Hanami web framework.

In Github, there is a Async Gem(https://github.com/socketry/async).

When using green threads/fibers/coroutines, an interesting technique to make signal handling safer is to run the signal handler asynchronously on a separate fiber/green thread. That way most of the problems of dealing with signals go away, and there's basically no limitation on what you can do inside the signal handler.

I've successfully used this technique in Polyphony [1], a fiber-based Ruby gem for writing concurrent programs. When a signal occurs, Polyphony creates a special-purpose fiber that runs the signal handling code. The fiber is put at the head of the run queue, and is resumed once the currently executed fiber yields control.

[1] https://github.com/digital-fabric/polyphony

Read the release notes here: https://github.com/orgs/digital-fabric/discussions/110 The Polyphony docs: https://www.rubydoc.info/gems/polyphony The Polyphony repository: https://github.com/digital-fabric/polyphony

Polyphony is a gem for building highly-concurrent Ruby programs. It utilizes Ruby fibers to provide a high-performance safe environment for launching any number of concurrent operations. Under the hood, Polyphony employs io_uring to maximize I/O performance (libev is used on platforms other than recent Linux kernels).

Is monkey-patching inherently bad? Should its use make Polyphony illegitimate? These are the questions I'm exploring in my latest article.

how is this diff from: https://github.com/digital-fabric/polyphony

Infinite loops are great for expressing long-running concurrent operations. In this article I’ll discuss the use of infinite loops as a major construct when writing concurrent apps in Ruby using Polyphony. I’ll show how infinite loops differ from normal, finite ones; how they can be used to express long-running tasks in a concurrent environment; and how they can be stopped. Read it now!

Polyphony is a library for writing highly concurrent Ruby apps. Polyphony harnesses Ruby fibers and a powerful io_uring-based I/O runtime to provide a solid foundation for building high-performance concurrent Ruby apps.

> Curious if there’s anything public about improving ruby performance from the I/O angle mentioned in the post.

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).

[0] https://github.com/digital-fabric/polyphony