4 ms·

Can the discussions here try to stay away from Go bashing. This post is not about Go. It's about Structured concurrency VS background tasks. There's many inter

Can the discussions here try to stay away from Go bashing. This post is not about Go. It's about Structured concurrency VS background tasks. There's many interesting discussions one can have about the latter but the former turns into toxicity. With that said. The Rust teams are very interestes in structured concurrency at the moment. Rust 1.63 is going to get scoped threads, which is structured concurrency for threading. Myself and others have also been looking into structured async, albeit it's not as easy to implement. I personally love the concept and I hope it takes off. You rarely need long running background tasks. If you do, you probably want to have a daemon running along side your main application using structured primitives and then dispatch work to them instead. This really simplifies the mental model when you get used to it.

jpgvm 4y ago
The OpenJDK team is also persuing structured concurrency so we should have multiple interpretations shortly to compare. Exciting stuff for folks that write highly concurrent software.
- zasdffaa 4y ago
  But should they be writing highly concurrent software, without thinking bloody hard first I mean? I can see this being the next Big Data or NoSQL 'must have' bandwagon.
  - masklinn 4y ago
    > But should they be writing highly concurrent software, without thinking bloody hard first I mean? Yes, by necessity. We're 15 years after the end of the race for frequency, and the end of moore's law is getting ever closer. Concurrency and parallelism are becoming table stakes for both reactivity and performances. This means making them reliably usable and composable is getting more and more important.
    - zasdffaa 4y ago
      @ohgodplsno (edit, and now @jpgvm's) have good answers grounded in a specific scenario which really makes their point well, but yours worries me. >> But should they be writing highly concurrent software, without thinking bloody hard first I mean? > Yes, by necessity. So we should not think about it first, just do it? And not consider whether there are better solutions such as checking we're using the right algos or cache-aligning our accesses or using a probabilistic filter before hitting the DB or.. Edit: no offense intended, the original question was meant as a rhetorical device to warn against dumbness and bandwaggoning. I am sure you too would not plough in unthinkingly but I'm afraid our industry's reaction is too often to do just that and it's such an expensive mistake, repeated over and over. It's a thoughtless jumping ahead that will lead to slower software, not faster. And buggier.
      - ddorian43 4y ago
        > And not consider whether there are better solutions such as checking we're using the right algos or cache-aligning our accesses or using a probabilistic filter before hitting the DB or.. It's mostly for io-intensive workloads. And for nicer debugging experience compared to callback hell. Nothing to do with NoSQL, or right algos, or cache-aligning when you just need to do 10M http requests/db-inserts/rpcs as fast/efficient/nicer-dev-experience as possible.
      - fijiaarone 4y ago
        I’m excited about concurrent Kubernetes clusters to compile our JavaScript frameworks to run on virtualized mainframes and achieve roughly equivalent performance and functionality of a pascal program running on an 8086 in 1985.
        zasdffaa 4y ago
        Serious note, I have worked on interfaces in pascal on a 80286 in that period, and the UI performance was crisp.
      - masklinn 4y ago
        > So we should not think about it first, just do it? It is much easier to bake concurrency and parallelism from the start than to retrofit it in an existing sequential project, even more so as it avoids sub-optimal patterns. > And not consider whether there are better solutions such as checking we're using the right algos or cache-aligning our accesses or using a probabilistic filter before hitting the DB or.. Why are you declaring that those are incompatible with concurrent programs, exactly?
  - ohgodplsno 4y ago
    If you do any kind of UI work, you are already considering carefully what to run on the UI thread (unless you're using JS but then you brought this upon yourself). Additionally, many reactive patterns require you to collect a flow and this blocks the whole thread. Launching a coroutine on a background dispatcher is safe and simple. There is a middle ground before highly concurrent, and it's "I don't really care what you do, but please use the cores i can have and don't block the main thread thank you"
    - zasdffaa 4y ago
      As elsewhere, yours is definitely not the case I was disputing but as UIs are not my area in the way you are clearly familiar with them, a question: What kind of application are you doing your UI for that can use all the cores?
      - swiftcoder 4y ago
        It's not a matter of using all the cores. It's a matter of not oversubscribing the one core that is receiving user input and updating the UI in response. UI frameworks are still (for the most part) extremely single-threaded, and pretty much leave it up to you to offload all your computation - or murder your UI responsiveness
      - ohgodplsno 4y ago
        Yep. The other response has it pretty right. I don't really care that i use _all_ the cores. Ideally i have one or two dedicated to IO, some for general computation, but most importantly i need things to get the fuck out of the main thread as fast as possible. User clicks somewhere, offload any computation to a coroutine on the background. If you don't do this, your UI will die. Even small, 50ms calculations are dreadful if ran on the UI thread. That means 3 dropped frames. Structured concurrency just means that i can both not really care where it goes, be generous on coroutines (I have only screwed up once, and that was by having hundreds of threads deadlocking on database access. Otherwise, you most likely have... 50 running at worst?). Structured concurrency also means that the moment i drop out of a screen, every computation launched in the context of this screen and not a higher level is just dropped immediately, meaning it runs just when I need it to
  - jpgvm 4y ago
    Well I don't know about most people but to speak for myself I mostly write high performance network servers, databases and queues and in my world concurrency (if not parallelism) is strictly necessary. For me it's also not a recent development or a fad, it's been this way my entire ~15ish year career. I imagine folks writing Web software, UIs and heavy desktop applications will also benefit from these developments but those areas are out of my core expertise so I can't speak to exactly how useful structured concurrency will be for them however I can see very clear applications for my domain.
    - zasdffaa 4y ago
      Yours is definitely not the case I was disputing.
andrewl-hn 4y ago
Swift has task-based structured concurrency since last year, and it looks really nice. https://developer.apple.com/wwdc21/10134 https://developer.apple.com/wwdc21/10134
- conradludgate 4y ago
  Very interesting. Thanks for sharing!
tialaramex 4y ago
Structured async sounds like a very interesting idea, this is definitely a space where it feels intuitively as though there should be a better way to express what we mean and get roughly the same machine code but better human understanding for both author and future maintenance programmers - if somebody nails this it could be as big a deal as the loop constructs in modern programming.
ignoramous 4y ago
> I personally love the concept and I hope it takes off I have used structured concurrency with Kotlin and you are right, it is absolutely easier to reason about concurrent code that way. https://elizarov.medium.com/structured-concurrency-722d765aa952 https://elizarov.medium.com/structured-concurrency-722d765aa...
pca006132 4y ago
Structured programming can guarantee that the control flow graph has constant treewidth[0], which enabled the use of parameterized algorithms for efficient static analysis. Wondering if structured concurrency can impose some additional constraints on the ordering of tasks that makes it easier to analyze, e.g. for linearizability or other properties. [0]: Mikkel Thorup. 1998. All structured programs have small tree width and good register allocation

jpgvm 4y ago

The OpenJDK team is also persuing structured concurrency so we should have multiple interpretations shortly to compare. Exciting stuff for folks that write highly concurrent software.

zasdffaa 4y ago
But should they be writing highly concurrent software, without thinking bloody hard first I mean? I can see this being the next Big Data or NoSQL 'must have' bandwagon.
- masklinn 4y ago
  > But should they be writing highly concurrent software, without thinking bloody hard first I mean? Yes, by necessity. We're 15 years after the end of the race for frequency, and the end of moore's law is getting ever closer. Concurrency and parallelism are becoming table stakes for both reactivity and performances. This means making them reliably usable and composable is getting more and more important.
  - zasdffaa 4y ago
    @ohgodplsno (edit, and now @jpgvm's) have good answers grounded in a specific scenario which really makes their point well, but yours worries me. >> But should they be writing highly concurrent software, without thinking bloody hard first I mean? > Yes, by necessity. So we should not think about it first, just do it? And not consider whether there are better solutions such as checking we're using the right algos or cache-aligning our accesses or using a probabilistic filter before hitting the DB or.. Edit: no offense intended, the original question was meant as a rhetorical device to warn against dumbness and bandwaggoning. I am sure you too would not plough in unthinkingly but I'm afraid our industry's reaction is too often to do just that and it's such an expensive mistake, repeated over and over. It's a thoughtless jumping ahead that will lead to slower software, not faster. And buggier.
    - ddorian43 4y ago
      > And not consider whether there are better solutions such as checking we're using the right algos or cache-aligning our accesses or using a probabilistic filter before hitting the DB or.. It's mostly for io-intensive workloads. And for nicer debugging experience compared to callback hell. Nothing to do with NoSQL, or right algos, or cache-aligning when you just need to do 10M http requests/db-inserts/rpcs as fast/efficient/nicer-dev-experience as possible.
    - fijiaarone 4y ago
      I’m excited about concurrent Kubernetes clusters to compile our JavaScript frameworks to run on virtualized mainframes and achieve roughly equivalent performance and functionality of a pascal program running on an 8086 in 1985.
      - zasdffaa 4y ago
        Serious note, I have worked on interfaces in pascal on a 80286 in that period, and the UI performance was crisp.
    - masklinn 4y ago
      > So we should not think about it first, just do it? It is much easier to bake concurrency and parallelism from the start than to retrofit it in an existing sequential project, even more so as it avoids sub-optimal patterns. > And not consider whether there are better solutions such as checking we're using the right algos or cache-aligning our accesses or using a probabilistic filter before hitting the DB or.. Why are you declaring that those are incompatible with concurrent programs, exactly?
- ohgodplsno 4y ago
  If you do any kind of UI work, you are already considering carefully what to run on the UI thread (unless you're using JS but then you brought this upon yourself). Additionally, many reactive patterns require you to collect a flow and this blocks the whole thread. Launching a coroutine on a background dispatcher is safe and simple. There is a middle ground before highly concurrent, and it's "I don't really care what you do, but please use the cores i can have and don't block the main thread thank you"
  - zasdffaa 4y ago
    As elsewhere, yours is definitely not the case I was disputing but as UIs are not my area in the way you are clearly familiar with them, a question: What kind of application are you doing your UI for that can use all the cores?
    - swiftcoder 4y ago
      It's not a matter of using all the cores. It's a matter of not oversubscribing the one core that is receiving user input and updating the UI in response. UI frameworks are still (for the most part) extremely single-threaded, and pretty much leave it up to you to offload all your computation - or murder your UI responsiveness
    - ohgodplsno 4y ago
      Yep. The other response has it pretty right. I don't really care that i use _all_ the cores. Ideally i have one or two dedicated to IO, some for general computation, but most importantly i need things to get the fuck out of the main thread as fast as possible. User clicks somewhere, offload any computation to a coroutine on the background. If you don't do this, your UI will die. Even small, 50ms calculations are dreadful if ran on the UI thread. That means 3 dropped frames. Structured concurrency just means that i can both not really care where it goes, be generous on coroutines (I have only screwed up once, and that was by having hundreds of threads deadlocking on database access. Otherwise, you most likely have... 50 running at worst?). Structured concurrency also means that the moment i drop out of a screen, every computation launched in the context of this screen and not a higher level is just dropped immediately, meaning it runs just when I need it to
- jpgvm 4y ago
  Well I don't know about most people but to speak for myself I mostly write high performance network servers, databases and queues and in my world concurrency (if not parallelism) is strictly necessary. For me it's also not a recent development or a fad, it's been this way my entire ~15ish year career. I imagine folks writing Web software, UIs and heavy desktop applications will also benefit from these developments but those areas are out of my core expertise so I can't speak to exactly how useful structured concurrency will be for them however I can see very clear applications for my domain.
  - zasdffaa 4y ago
    Yours is definitely not the case I was disputing.

andrewl-hn 4y ago

Swift has task-based structured concurrency since last year, and it looks really nice. https://developer.apple.com/wwdc21/10134 https://developer.apple.com/wwdc21/10134

conradludgate 4y ago
Very interesting. Thanks for sharing!

tialaramex 4y ago

Structured async sounds like a very interesting idea, this is definitely a space where it feels intuitively as though there should be a better way to express what we mean and get roughly the same machine code but better human understanding for both author and future maintenance programmers - if somebody nails this it could be as big a deal as the loop constructs in modern programming.

ignoramous 4y ago

> I personally love the concept and I hope it takes off I have used structured concurrency with Kotlin and you are right, it is absolutely easier to reason about concurrent code that way. https://elizarov.medium.com/structured-concurrency-722d765aa952 https://elizarov.medium.com/structured-concurrency-722d765aa...

pca006132 4y ago

Structured programming can guarantee that the control flow graph has constant treewidth[0], which enabled the use of parameterized algorithms for efficient static analysis. Wondering if structured concurrency can impose some additional constraints on the ordering of tasks that makes it easier to analyze, e.g. for linearizability or other properties. [0]: Mikkel Thorup. 1998. All structured programs have small tree width and good register allocation