3 ms·

It feels like that's coupling some concerns together. Functions that do IO are more likely to fail, yes, but that doesn't have to do with their async-ness or t

It feels like that's coupling some concerns together. Functions that do IO are more likely to fail, yes, but that doesn't have to do with their async-ness or their slowness.

lolinder 3y ago
It's not that async-ness causes things to fail more easily, it's that if you're going to make a function async it's because it interacts with the outside world in some fashion, and interaction with the outside world is slow and likely to fail. We could use a different name for that concept to make it more clear why these ideas are related, like `IO`, but in practice async=IO in most code.
- pgwhalen 3y ago
  It seems like we're on the same page. My point is that your last comment... > in practice async=IO in most code does not need to be true. We will never avoid the complexity of IO, but we can avoid the complexity of async, and virtual threads provide us that opportunity.
  - lolinder 3y ago
    I didn't mean that = to be transitive. All async is IO, but obviously some IO is not async. > We will never avoid the complexity of IO, but we can avoid the complexity of async Because we can never avoid the complexity of IO, having a language construct that makes it obvious when you're using IO is valuable. IO code is different in kind than non-IO code, and having it explicitly marked helps keep the mess that is IO from propagating its problems throughout the rest of your code.
    - pgwhalen 3y ago
      I don't entirely disagree that treating IO as something special at the linguistic level is a good idea, but I do think that async is a wildly indirect and confusing way to achieve that. Language designers don't add async to make IO look special, they add it as a concurrent programming model.
- samus 3y ago
  When IO fails, it doesn't matter a single bit whether the call occured on a virtual or on a platform thread. The likelyhood of failure deserves coloring, but Java already offers a mechanism for that.

It feels like that's coupling some concerns together. Functions that do IO are more likely to fail, yes, but that doesn't have to do with their async-ness or their slowness.

lolinder 3y ago

It's not that async-ness causes things to fail more easily, it's that if you're going to make a function async it's because it interacts with the outside world in some fashion, and interaction with the outside world is slow and likely to fail. We could use a different name for that concept to make it more clear why these ideas are related, like `IO`, but in practice async=IO in most code.

pgwhalen 3y ago
It seems like we're on the same page. My point is that your last comment... > in practice async=IO in most code does not need to be true. We will never avoid the complexity of IO, but we can avoid the complexity of async, and virtual threads provide us that opportunity.
- lolinder 3y ago
  I didn't mean that = to be transitive. All async is IO, but obviously some IO is not async. > We will never avoid the complexity of IO, but we can avoid the complexity of async Because we can never avoid the complexity of IO, having a language construct that makes it obvious when you're using IO is valuable. IO code is different in kind than non-IO code, and having it explicitly marked helps keep the mess that is IO from propagating its problems throughout the rest of your code.
  - pgwhalen 3y ago
    I don't entirely disagree that treating IO as something special at the linguistic level is a good idea, but I do think that async is a wildly indirect and confusing way to achieve that. Language designers don't add async to make IO look special, they add it as a concurrent programming model.
samus 3y ago
When IO fails, it doesn't matter a single bit whether the call occured on a virtual or on a platform thread. The likelyhood of failure deserves coloring, but Java already offers a mechanism for that.