4 ms·

It would be really nice if the Rust standard library were to get structured concurrency similar to what Ada has: https://learn.adacore.com/courses/Ada_For_The_

It would be really nice if the Rust standard library were to get structured concurrency similar to what Ada has: https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Developer/chapters/11_Concurrency.html https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel... https://en.wikibooks.org/wiki/Ada_Style_Guide/Concurrency https://en.wikibooks.org/wiki/Ada_Style_Guide/Concurrency It allows multiple concurrent taks to run within a parent block of code and terminate at the end of the block. It is extremely useful for embedded and parallel programming which would help Rust to further succeed in those areas. So much concurrent and parallel Rust code relies on third-party libraries because the standard library offers primitives that work but lack the "creature comforts" that developers prefer. It is good that futures-concurrency offers better choices for Rust developers, but ultimately it would be great for the Rust to adopt better concurrency APIs.

bluejekyll 3y ago
This sounds like what scoped threads at least partially provides. It was in pre-1.0 Rust, got moved to a 3rd party library, but stabilized in 1.63: https://doc.rust-lang.org/stable/std/thread/fn.scope.html https://doc.rust-lang.org/stable/std/thread/fn.scope.html
- thesuperbigfrog 3y ago
  Some of the features are there, but not all: It looks like each thread in scoped threads must be "manually started" (not launched automatically at the beginning of the scope). No defined mechanisms for synchronization or data passing between scoped threads. There are probably ways it can be done, but I am not sure what approach would work best without some experimentation.
  - wongarsu 3y ago
    In Rust, the idiomatic solutions for data-passing would be a fifo channel (either std::sync::mpsc from the standard library or one of the popular libraries (crossbeam or flume)), and the solution for synchronization would be one-shot channels or zero-capacity channels. Or you can just manually join the threads you started
jgraettinger1 3y ago
futures::join!() and friends do what you’re after admirably. Is the complaint that something is still missing, or that it’s not in the standard library?
- Jtsummers 3y ago
  Ada's tasks don't require an explicit join, they're lexically scoped. So if you have a procedure with two subtasks that procedure will not terminate until those two subtasks have terminated (by whatever means they may be terminated, running to completion or an explicit `abort SomeTask;`). Here are a couple pages on Tasking in Ada: https://learn.adacore.com/courses/intro-to-ada/chapters/tasking.html https://learn.adacore.com/courses/intro-to-ada/chapters/task... - doesn't compare to any other languages, just Ada code. https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Developer/chapters/11_Concurrency.html https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel... - Includes comparisons to Java and C++. http://www.ada-auth.org/standards/22rm/html/RM-9-8.html http://www.ada-auth.org/standards/22rm/html/RM-9-8.html - more on cancellation via the abort statement. If you abort a task with subtasks running, it will terminate all of them. Ada has some escape hatches around its task system that "breaks" from structured concurrency, but pretty much everything people have been asking for around structured concurrency is already in Ada and mostly the default behavior.
swader999 3y ago
How possible is this kind of thing in Golang, in Elixer? I'm trying to choose tech for parsing, processing, calculating, and applying complex business rules to a massive csv parsing pipeline. Early stages but golang seems like the right candidate.
- lenkite 3y ago
  All this is easily possible. You can leverage fan-out/fan-in/pipeline concurrency patterns in Go.
  - anacrolix 3y ago
    It's really awful in Go to create concurrency patterns. In particular because the generics are clunky and verbose, and there are no type classes/traits. There's also no good cancellation convention: Context is verbose, dynamically typed, and not used in all the standard interfaces.
- matreyes 3y ago
  This is, actually, the erlang/elixir concurrency model, (with a lot of tooling behind for doing it well).
  - adamwk 3y ago
    Isn’t erlang a very different, almost opposite concurrency model? I’m not an erlang expert but async message passing is a very different style. The limitation around background tasks in structured concurrency is trivial in erlang for example
    - matreyes 3y ago
      Yes, but proceses are supervised (in a tree structure). So you have the same warranties described in structured concurrency
      - swader999 3y ago
touisteur 3y ago
Yet I yearn for higher tasking APIs such as a standard task-tree or task-graph. The parrafin library helps a bit, but it's still heavy handed and feels abandoned (yes I or whomever I'm working for could take the maintainer mantle or write language proposals, but I don't actually know which solution would be best...). The sparkel/parasail language prototypes (or actual implementations) had some interesting ideas but I'm not sure how it panned out and what the lessons learned where.

bluejekyll 3y ago

This sounds like what scoped threads at least partially provides. It was in pre-1.0 Rust, got moved to a 3rd party library, but stabilized in 1.63: https://doc.rust-lang.org/stable/std/thread/fn.scope.html https://doc.rust-lang.org/stable/std/thread/fn.scope.html

thesuperbigfrog 3y ago
Some of the features are there, but not all: It looks like each thread in scoped threads must be "manually started" (not launched automatically at the beginning of the scope). No defined mechanisms for synchronization or data passing between scoped threads. There are probably ways it can be done, but I am not sure what approach would work best without some experimentation.
- wongarsu 3y ago
  In Rust, the idiomatic solutions for data-passing would be a fifo channel (either std::sync::mpsc from the standard library or one of the popular libraries (crossbeam or flume)), and the solution for synchronization would be one-shot channels or zero-capacity channels. Or you can just manually join the threads you started

jgraettinger1 3y ago

futures::join!() and friends do what you’re after admirably. Is the complaint that something is still missing, or that it’s not in the standard library?

Jtsummers 3y ago
Ada's tasks don't require an explicit join, they're lexically scoped. So if you have a procedure with two subtasks that procedure will not terminate until those two subtasks have terminated (by whatever means they may be terminated, running to completion or an explicit `abort SomeTask;`). Here are a couple pages on Tasking in Ada: https://learn.adacore.com/courses/intro-to-ada/chapters/tasking.html https://learn.adacore.com/courses/intro-to-ada/chapters/task... - doesn't compare to any other languages, just Ada code. https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Developer/chapters/11_Concurrency.html https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel... - Includes comparisons to Java and C++. http://www.ada-auth.org/standards/22rm/html/RM-9-8.html http://www.ada-auth.org/standards/22rm/html/RM-9-8.html - more on cancellation via the abort statement. If you abort a task with subtasks running, it will terminate all of them. Ada has some escape hatches around its task system that "breaks" from structured concurrency, but pretty much everything people have been asking for around structured concurrency is already in Ada and mostly the default behavior.

swader999 3y ago

How possible is this kind of thing in Golang, in Elixer? I'm trying to choose tech for parsing, processing, calculating, and applying complex business rules to a massive csv parsing pipeline. Early stages but golang seems like the right candidate.

lenkite 3y ago
All this is easily possible. You can leverage fan-out/fan-in/pipeline concurrency patterns in Go.
- anacrolix 3y ago
  It's really awful in Go to create concurrency patterns. In particular because the generics are clunky and verbose, and there are no type classes/traits. There's also no good cancellation convention: Context is verbose, dynamically typed, and not used in all the standard interfaces.
matreyes 3y ago
This is, actually, the erlang/elixir concurrency model, (with a lot of tooling behind for doing it well).
- adamwk 3y ago
  Isn’t erlang a very different, almost opposite concurrency model? I’m not an erlang expert but async message passing is a very different style. The limitation around background tasks in structured concurrency is trivial in erlang for example
  - matreyes 3y ago
    Yes, but proceses are supervised (in a tree structure). So you have the same warranties described in structured concurrency
    - swader999 3y ago

touisteur 3y ago

Yet I yearn for higher tasking APIs such as a standard task-tree or task-graph. The parrafin library helps a bit, but it's still heavy handed and feels abandoned (yes I or whomever I'm working for could take the maintainer mantle or write language proposals, but I don't actually know which solution would be best...). The sparkel/parasail language prototypes (or actual implementations) had some interesting ideas but I'm not sure how it panned out and what the lessons learned where.