3 ms·

> You'll typically have an idea of whether or not a function performs IO from the start. I think GP's point is: why does that matter? Much writing on Async/Aw

> You'll typically have an idea of whether or not a function performs IO from the start. I think GP's point is: why does that matter? Much writing on Async/Await roughly correlates IO with "slow". GP rightly points out that "slow" is imprecise, changes, means different things to different people and/or use cases. I completely get the intuition: "there's lag in the [UI|server|...], what's slowing it down?". But the reality is that trying to formalise "slow" in the type system is nigh on impossible - because "slow" for one use case is perfectly acceptable for another.

littlestymaar 3y ago
While slow in absolute depends on lots of factors, the relative slowness of things doesn't so much. Whatever the app or the device, accessing a register is always going to be faster than random places in RAM, which is always going to be faster than fetching something on disk and even moreso if we talk about fetching stuff over the network. No matter how hardware progresses, latency hierarchy is doomed to stay. That doesn't mean it's the only factor of slowness, and that async/await solves all issues, but it's a tool that helps, a lot, to fight against very common sources of performance bugs (like how the borrow checker is useful when it protects against the nastiest class of memory vulnerabilities, even if it cannot solve all security issues). Because the situation where “my program is stupidly waiting for some IO even though I don't even need the result right now and I could do something in the meantime” is something that happens a lot.
- cesarb 3y ago
  > Whatever the app or the device, accessing a register is always going to be faster than random places in RAM, which is always going to be faster than fetching something on disk and even moreso if we talk about fetching stuff over the network. The network is special: the time it takes to fetch something over the network can be arbitrarily large, or even infinite (this can also apply to disk when running over networked filesystems), while for registers/RAM/disk (as long as it's a local disk which is not failing) the time it takes is bounded. That's the reason why async/await is so popular when dealing with the network.
  - Nullabillity 3y ago
    PCIe is a network. USB is a network. There is no such thing as a resource with a guaranteed response time.
Nullabillity 3y ago
Even if you ignore performance completely, IO is unreliable. IO is unpredictable. IO should be scrutinized.
- ngrilly 3y ago
  When using SSD or eNVM, why would local IO be more unreliable/unpredictable than local RAM?
  - riskable 3y ago
    Don't assume your process is the only process. You have to share resources like storage and RAM with everything else on the system. Just a single, simple Java app can gobble up all available RAM if you don't tell it otherwise.
    - ngrilly 3y ago
      Exactly. Which means other processes running on the same server can cause latency on disk access but also on RAM, which was the point I was trying to make :)

littlestymaar 3y ago

While slow in absolute depends on lots of factors, the relative slowness of things doesn't so much. Whatever the app or the device, accessing a register is always going to be faster than random places in RAM, which is always going to be faster than fetching something on disk and even moreso if we talk about fetching stuff over the network. No matter how hardware progresses, latency hierarchy is doomed to stay. That doesn't mean it's the only factor of slowness, and that async/await solves all issues, but it's a tool that helps, a lot, to fight against very common sources of performance bugs (like how the borrow checker is useful when it protects against the nastiest class of memory vulnerabilities, even if it cannot solve all security issues). Because the situation where “my program is stupidly waiting for some IO even though I don't even need the result right now and I could do something in the meantime” is something that happens a lot.

cesarb 3y ago
> Whatever the app or the device, accessing a register is always going to be faster than random places in RAM, which is always going to be faster than fetching something on disk and even moreso if we talk about fetching stuff over the network. The network is special: the time it takes to fetch something over the network can be arbitrarily large, or even infinite (this can also apply to disk when running over networked filesystems), while for registers/RAM/disk (as long as it's a local disk which is not failing) the time it takes is bounded. That's the reason why async/await is so popular when dealing with the network.
- Nullabillity 3y ago
  PCIe is a network. USB is a network. There is no such thing as a resource with a guaranteed response time.

Nullabillity 3y ago

Even if you ignore performance completely, IO is unreliable. IO is unpredictable. IO should be scrutinized.

ngrilly 3y ago
When using SSD or eNVM, why would local IO be more unreliable/unpredictable than local RAM?
- riskable 3y ago
  Don't assume your process is the only process. You have to share resources like storage and RAM with everything else on the system. Just a single, simple Java app can gobble up all available RAM if you don't tell it otherwise.
  - ngrilly 3y ago
    Exactly. Which means other processes running on the same server can cause latency on disk access but also on RAM, which was the point I was trying to make :)