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.

I mean, aside from bypassing the whole point of having them.

There are plenty of use cases. Like having your code signed, but putting a license key or access tokens or endpoint URLs into the unsigned part. That way you can sign binaries with your heavily guarded key, but still have some web server give people individualized binaries that don't have to ask for information (better UX if you install it once, or a big deal for software meant to be rolled out across many machines).

Of course software can abuse it by loading code from the unsigned portion, but that requires code in the signed portion to be complicit. In that case the signature still does its job of telling you exactly who was responsible for that fuck-up.

We do this where I work, and we HEAVILY verify all information that comes in from the unsigned/unauthenticated parts of the code. Not only types checks, but regex checks, and other validations. And if there's something there that shouldn't be there our program will kill itself. We don't even show any error prompts or anything just incase.

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

Code is logic. Data is state. To say that code is state is like saying that electrical circuits are electricity.

Code carries data in the same way that electrical circuits carry electricity.

State is data over time!

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.

Interesting, but I read some issues with Benchmade showing it's not actually reproducible regarding performance improvement over epoll and epoll still faster.

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.

I'm guessing this problem also applies to Action Cable?

Okay, that makes sense.