I can't recall for sure, but I suspect I looked at Mojo for the first time five or six years ago long enough to write the test that Ovid uses for his consulting company (he didn't like some of my design decisions, I disagreed, but it is his prerogative), and not again since.

However, there are still some fundamental problems with perl asynchronicity. That is, any XS driver not aware of it will have to be managed somehow. Coro (which I used for the CB stats, the original topic) did this by shunting them off to separate (real) threads, I believe. I'd have to look at the code, but somehow I think now that the code I was using just did a hard wait on the db, which is kind of horrible, even worse than consuming extra threads.

As for Mojo::Pg, I would be somewhat surprised if DBD::Pg wasn't using threads in the background. Ideally it'd be just one thread for all of the aysnc queries, so hopefully that's the solution here. However, I would be even more surprised if most of the DB drivers support this async behaviour. Yes, I've chosen Postgres for this application, but at this point I could pretty easily change my mind. At the end of the day, some drivers will not see the async as required by DBI, and just not implement. Also, this game originally was based on DBIx::Class, and maybe this has changed, but I don't recall it supporting the async version of mysql or postgres. (This is what I mean by the whole stack needing to support the async nature.)

And then "callbacks" is exactly the problem that async/await is supposed to solve (with javascript almost explicitly being that - to avoid Promises with callbacks inside Promises of callbacks inside ... just use async/await). But this is a bit of a digression - the point really comes down to

1. Co-routines are way better than threads. Event loops are related - similar performance, though considerably more annoying to use. A single coroutine thread can handle dozens, if not hundreds, of actions with less overhead (compared to threads), as long as it's mostly I/O driven and can be waited upon by the main event loop. I've managed parallel processing across clusters of 40+ AIX systems using ssh under AnyEvent, and the management node was essentially idle, when coworkers were writing their code to do one node at a time. I was a huge fan. But there are limits.
2. Languages where coroutines are native are just going to give every driver the incentive to do things in that one, single, standard way (which is what AnyEvent was supposed to provide, but, due to certain factors I won't get into, was largely rejected by the community at large), and there is a huge advantage there.
3. Combining coroutines and real threads, using threadpools for the coroutines, and the amount of work you can get done trivially is immense.

Believe me, I'd avoid anything from Microsoft if I could, but they've produced a language and virtual machine here that actually is a really good balance between competing requirements. The only thing I'm really missing at this point is the type-and-run aspect of perl, although I could do with elevating regexes to first-class language constructs like in Perl as well :) Things like perl -ML -E 'L->do_something(shift)' 12345 was really handy. I can still share libraries easily enough, but not THAT easy.