ioquatix

Have you actually benchmarked this and published the benchmarks somewhere?

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

Sounds like a useful feature to me.

"All Programming is about State". All code is state. All state is code. It's turtles all the way down.

It's adopted by Ruby: <https://github.com/socketry/io-event> which is used by <https://github.com/socketry/async> which is part of the Ruby 3+ Fiber Scheduler for light weight concurrency. It shows promising performance.

The fiber scheduler also hooks into the `Timeout` module to provide safe(r) timeouts using the event loop.

Every task is a promise you can wait on for the result. Concurrent fan out is trivial.

That's pretty accurate.

The gem namespace was transferred to me some time around 2017.

ActiveRecord does work but it’s hugely limited because they have explicit per-thread resource pools which we can’t get around very easily.

When designing an API in Rust which performs IO, you have to make a decision whether you want it to be synchronous, asynchronous, or both.

Why must that be true? Why can't you write the interface once, and have concurrency be an implementation detail?

So what are we going to do about it?

Extinction :(

Nope, they are totally different. However, the DB gem is an interface/driver similar to PHP's PDO, while AR is a set of drivers, interfaces and high level ORM interfaces. In theory, one could probably use DB as a driver under AR. One person even basically uses AR to generate SQL and then executes it with the DB gem, which I thought was pretty clever.

The fiber scheduler solves this as concurrent execution is now built into the core of Ruby 3.

Also, it turns out the `pg` is also partially non-blocking. But AR may need to improve their connection pool implementation.

Non-blocking Postgres https://github.com/socketry/db-postgres

Non-blocking MariaDB https://github.com/socketry/db-mariadb

Yes, it was. It was originally a front end and back end (query server) for CouchDB. But CouchDB 2 really went in a different direction to what I expected with query servers so I gave up and decided to pivot in a different direction with the code base.

https://github.com/ioquatix/relaxo-query-server FYI.

For the lolz: https://github.com/ioquatix/relaxo

This problem is being addressed in Ruby 3.

Ruby FFI has been experimenting with provided support for kicking external functions to background threads with a single keyword argument.

https://github.com/socketry/async-pool

We can do the same model for Ruby (preemption of event driven fibers) and may choose to do so in the future. We are just taking one step at a time.

Yes, you run one scheduler per core.

async/await is a huge anti-pattern IMHO.

Well, it's not a list. It's just a set of hooks. But that's basically it.

Actually... I've implemented both client and server side HTTP/2 push and I'd say... it's a hack and we should deprecate it and remove it from the spec.

Yes, it lets you implement event loop for Ruby. We use fibers to avoid callback hell and avoid rewriting existing code. This is covered in my talk here: https://www.youtube.com/watch?v=qKQcUDEo-ZI

Latest talk about scheduler: https://www.youtube.com/watch?v=Y29SSOS4UOc

Recent summary of scheduler, a little bit out of date (changes to interface): https://www.codeotaku.com/journal/2020-04/ruby-concurrency-f...

Yes.