3 ms·
This is because the original article talked about a couple different things under the same title of a "coloring" problem: 1. JS has no way to wait for results
by pornel 6y ago
This is because the original article talked about a couple different things under the same title of a "coloring" problem:
1. JS has no way to wait for results of async functions in a sync context. This creates hard split between sync and async "colors". This is what most people agree is the major problem.
2. C# can avoid the split, but the syntax for using sync and async is different. The original article wasn't very clear about why this is bad, other than it exists.
The second case gets interpreted as either:
2a. Programming languages should be able to generically abstract over sync/async syntax.
2b. Programming languages shouldn't have a different sync/async syntax in the first place.
Rust's case is consistently:
- It generally doesn't have the problem #1. Sync code can wait for async. Async code can spawn sync on a threadpool. There are some gotchas and boilerplate, but this kind of "color" isn't an unsolvable dead-end like it is in JS.
- It has distinct syntax and execution model for async, which still counts as "color" (#2) per the original article. However, Rust can abstract over sync and async, so it doesn't have the problem #2a. The syntactical distinction is very intentional, so it doesn't consider #2b to be a problem at all.
- merb 6y agothe problem is that if you introduce async, your could should preferably async all the way to the bottom. of course you can trick yourself by using thread pools and move long running functions to them, but not everybody knows that. of course sync functions have the same problem (not the same problem, but it's the same concept, just in the other way), except that most frameworks just deal with it at the very front, so developers do not need to deal with it.
- pornel 6y agoThe whole point is that use of async doesn't need to be infectious. You may want to make everything async for elegance and consistency, but it's not a requirement strong enough to cause problems. If you have a library that is sync-only, it's fine. If you have a large project and can't be bothered to rewrite everything to be async, it's fine. "Not everybody knows (how to do) that" is a weak argument, because it's a relatively straightforward thing to learn: if it can block, wrap it in `spawn_blocking()`.
- ibraheemdev 6y ago> of course you can trick yourself by using thread pools and move long running functions to them How is that tricking yourself? Blocking code exists, and you will almost always run into it one way or the other.