4 ms·
Please, someone, correct me if I've misunderstood. The big difference appears to be that async Ruby does not merely give you an easy sugar to perform the sync-
by Smaug123 5y ago
Please, someone, correct me if I've misunderstood.
The big difference appears to be that async Ruby does not merely give you an easy sugar to perform the sync-over-async antipattern you have described. The real innovation is that, as far as the user is concerned, Ruby is magically turning blocking methods into non-blocking ones.
- ioquatix 5y agoThat's pretty accurate.
- nixpulvis 5y agoThat's basically how I'm thinking of things as well. To illustrate a bit further, consider the following: Given a blocking method call `foo(x)`, I can make it non-blocking by wrapping it in a "thunk" as `λx.foo(x)`. Where things start to get interesting is when I add another method call `foo(x) + bar(x)`. Now to keep things "async" I need to transform the abstraction into something more like `λx.foo(x) + λx.bar(x)`, and have the `+` call dispatch both fibers and wait for them before performing its operation. Doing this automatically seems pretty cool, I'll have to think about this a bit more sometime.