ioquatix

Have you actually benchmarked this and published the benchmarks somewhere?

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.

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.