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

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.

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

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?

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/task... - doesn't compare to any other languages, just Ada code.

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 - 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.

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.

All this is easily possible. You can leverage fan-out/fan-in/pipeline concurrency patterns in Go.

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.

This is, actually, the erlang/elixir concurrency model, (with a lot of tooling behind for doing it well).

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

Yes, but proceses are supervised (in a tree structure). So you have the same warranties described in structured concurrency

Yeah this seems compelling, especially the economics of it when paying for machine time.

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.