2 ms·

The tradeoff in Go as I understand it is that you can't know whether the runtime will opt for single threaded concurrency or parallelism? That seems like it cou

The tradeoff in Go as I understand it is that you can't know whether the runtime will opt for single threaded concurrency or parallelism? That seems like it could be a headache, but there will always be a headache somewhere in concurrent programming. Perhaps the Go headache is smaller than the C# one in this case. Doing blocking IO together with UI code is pretty bad in general though. Disks are certainly not quick enough to have File.Delete(...) be blocking unless you know the disk isn't on a network server which is aboard a satellite leaving the solar system or whatever edge case you'll invariably run into.

flohofwoe 2y ago
> Doing blocking IO together with UI code is pretty bad in general though. Non-blocking IO without multithreading doesn't require async/await though, all operating systems have had non-blocking IO functions for decades, they just never made it into language stdlibs.
- alkonaut 2y ago
  Yes, and blocking is usually faster. It's entirely correct for code to be blocking by default because it shouldn't be assuming that there is any interactivity going. If I want to make a console utility that scans some files then I don't need to worry about whether a UI is being repainted. So I completely agree with treating asynchronous as the odd case, and blocking as default which is not what JS does but it's what e.g. .NET IO does, and if you want to have a responsive UI together with IO you can often just combine a processing thread that blocks, and a UI thread that doesn't. The case where you'd want proper async IO is when you want to wait for 100 IO tasks each with unknown duration, where each is really async at the OS level anyway but your IO API doesn't expose that. Doing 100 threads isn't really a good option.
tightbookkeeper 2y ago
But most windows 98 era Ui programs were 1 or 2 threads…. You just handle events in order in a loop. It works and is far more responsive than what we have today. > Disks are certainly not quick enough to have File.Delete(...) be blocking What if you invoke a delete and then it fails and you want the user to respond? What will the state of your UI be when that happens?
- alkonaut 2y ago
  > What will the state of your UI be when that happens? If you can't do anything else until you know whether it was a success or failure, then you ensure that. E.g. you disable every single button that allows the user to do something else before the previous operation completes. Basically the theory is usually that you can allow the UI to "read" the program state while a "write" operation is still in flight. Typically this results in the user being able to for example scroll a document so it re-renders correctly etc. After the in-flight operation succeeds/fails, you can show the user the message if required, then enable new operations to happen. But the UI never stopped pumping messages so it was always responsive at least.
  - tightbookkeeper 2y ago
    > you disable every single button that allows the user to do something else before the previous operation completes. Wow you mean the whole program becomes unresponsive? Crazy! To address your main point, yes, scrolling, hover, etc can continue to work. But now you genuinely have two things your program is doing at once, and these must be coordinated. A gui framework typically handles this, with a separate thread (or separate OS process). So your thread that responds to events can block while the render/refresh continues doing its thing. With this design the problem goes away. Instead of writing code that disables the ui, issues a callback, waits to respond, you just literally write: If (!file.delete()) { Showerror() } This is the kind of code you can read, and put breakpoints on.
    - 6510 2y ago
      > Wow you mean the whole program becomes unresponsive? Crazy! It is using all resources to do what it was told to. Results depend on the magnitude of the task and the hardware available with a very large overlap where the difference doesn't matter at all. If blowing up complexity everywhere to solve a problem you probably wont have is a good thing is left as an exercise for the reader.
      - tightbookkeeper 2y ago

flohofwoe 2y ago

> Doing blocking IO together with UI code is pretty bad in general though. Non-blocking IO without multithreading doesn't require async/await though, all operating systems have had non-blocking IO functions for decades, they just never made it into language stdlibs.

alkonaut 2y ago
Yes, and blocking is usually faster. It's entirely correct for code to be blocking by default because it shouldn't be assuming that there is any interactivity going. If I want to make a console utility that scans some files then I don't need to worry about whether a UI is being repainted. So I completely agree with treating asynchronous as the odd case, and blocking as default which is not what JS does but it's what e.g. .NET IO does, and if you want to have a responsive UI together with IO you can often just combine a processing thread that blocks, and a UI thread that doesn't. The case where you'd want proper async IO is when you want to wait for 100 IO tasks each with unknown duration, where each is really async at the OS level anyway but your IO API doesn't expose that. Doing 100 threads isn't really a good option.

tightbookkeeper 2y ago

But most windows 98 era Ui programs were 1 or 2 threads…. You just handle events in order in a loop. It works and is far more responsive than what we have today. > Disks are certainly not quick enough to have File.Delete(...) be blocking What if you invoke a delete and then it fails and you want the user to respond? What will the state of your UI be when that happens?

alkonaut 2y ago
> What will the state of your UI be when that happens? If you can't do anything else until you know whether it was a success or failure, then you ensure that. E.g. you disable every single button that allows the user to do something else before the previous operation completes. Basically the theory is usually that you can allow the UI to "read" the program state while a "write" operation is still in flight. Typically this results in the user being able to for example scroll a document so it re-renders correctly etc. After the in-flight operation succeeds/fails, you can show the user the message if required, then enable new operations to happen. But the UI never stopped pumping messages so it was always responsive at least.
- tightbookkeeper 2y ago
  > you disable every single button that allows the user to do something else before the previous operation completes. Wow you mean the whole program becomes unresponsive? Crazy! To address your main point, yes, scrolling, hover, etc can continue to work. But now you genuinely have two things your program is doing at once, and these must be coordinated. A gui framework typically handles this, with a separate thread (or separate OS process). So your thread that responds to events can block while the render/refresh continues doing its thing. With this design the problem goes away. Instead of writing code that disables the ui, issues a callback, waits to respond, you just literally write: If (!file.delete()) { Showerror() } This is the kind of code you can read, and put breakpoints on.
  - 6510 2y ago
    > Wow you mean the whole program becomes unresponsive? Crazy! It is using all resources to do what it was told to. Results depend on the magnitude of the task and the hardware available with a very large overlap where the difference doesn't matter at all. If blowing up complexity everywhere to solve a problem you probably wont have is a good thing is left as an exercise for the reader.
    - tightbookkeeper 2y ago