5 ms·

"Spawning multiple tasks requires that each task be 'static, which means they cannot borrow data from their parent task." The lack of structured concurrency or

by api 3y ago

"Spawning multiple tasks requires that each task be 'static, which means they cannot borrow data from their parent task." The lack of structured concurrency or anything like thread::scope in async Rust can be quite a headache. Requiring tasks to be 'static basically forces you to Arc<> everything, at which point you start wondering why you aren't just using a GC'd language like Go, Java, or Kotlin.

andyferris 3y ago
I was wondering something similar. Is all of this a symptom of the fact that the whole async (and multithread) system isn't based on structure concurrency? Wouldn't a really deep embrace of structured concurrency work beautifully with the borrow checker? Or am I on the wrong track? Recently I read (I can't quite remember where, but I think it was in the context of actors) someone making out computational DAGs as "just a pipeline" - but this misses that a webserver or app or game or whatever should also have DAG-like computation graphs. I might be really on the wrong track here, but trying to jam all these independent "actors" into the one program seems odd - the game players, app users, web clients, etc are other actors. Your database might be an actor. But why would you want your own program to be a bunch of arbitrary actors that can interact with each other willy-nilly? Is there something useful you can do within a single process that isn't possible with structured concurrency?
- mwcampbell 3y ago
  Structured concurrency in Rust is a hard problem. Boats blogged about this before: https://without.boats/blog/the-scoped-task-trilemma/ https://without.boats/blog/the-scoped-task-trilemma/
  - andyferris 3y ago
    Ah thanks! I had seen this trilemma referred to before but never read the source until now. From the scoped task trilemma: > Assuming that we are not adding linear types to Rust, ... Going back to my earlier post, I still wonder if some (theoretical) language with linear types would be able to do structured concurrency with convenient borrows and so-on? (The issues seem related to late drops, leaks, etc).
- vacuity 3y ago
  Speaking entirely out of inexperience, perhaps it's a situation where you could theoretically do everything with structured concurrency, but you'd have to have deep understanding of all the details of your system, not to mention needing to update it if aspects change. So it might be less of a hassle in developer time and energy to have a looser model.
mwcampbell 3y ago
For me, the strongest reason to use Rust anyway is that Rust makes it practical to write a single library that can be efficiently embedded in multiple runtime environments. One probably wouldn't want to use a Go library, for example, in a C, Java, or Python project, even though it's possible with cgo. Of course, if a Rust library is using async under the hood, it'll probably run a main loop on its own thread. But that happens often enough in C and C++ libraries as well.

by api 3y ago

andyferris 3y ago

I was wondering something similar. Is all of this a symptom of the fact that the whole async (and multithread) system isn't based on structure concurrency? Wouldn't a really deep embrace of structured concurrency work beautifully with the borrow checker? Or am I on the wrong track? Recently I read (I can't quite remember where, but I think it was in the context of actors) someone making out computational DAGs as "just a pipeline" - but this misses that a webserver or app or game or whatever should also have DAG-like computation graphs. I might be really on the wrong track here, but trying to jam all these independent "actors" into the one program seems odd - the game players, app users, web clients, etc are other actors. Your database might be an actor. But why would you want your own program to be a bunch of arbitrary actors that can interact with each other willy-nilly? Is there something useful you can do within a single process that isn't possible with structured concurrency?

mwcampbell 3y ago
Structured concurrency in Rust is a hard problem. Boats blogged about this before: https://without.boats/blog/the-scoped-task-trilemma/ https://without.boats/blog/the-scoped-task-trilemma/
- andyferris 3y ago
  Ah thanks! I had seen this trilemma referred to before but never read the source until now. From the scoped task trilemma: > Assuming that we are not adding linear types to Rust, ... Going back to my earlier post, I still wonder if some (theoretical) language with linear types would be able to do structured concurrency with convenient borrows and so-on? (The issues seem related to late drops, leaks, etc).
vacuity 3y ago
Speaking entirely out of inexperience, perhaps it's a situation where you could theoretically do everything with structured concurrency, but you'd have to have deep understanding of all the details of your system, not to mention needing to update it if aspects change. So it might be less of a hassle in developer time and energy to have a looser model.

mwcampbell 3y ago

For me, the strongest reason to use Rust anyway is that Rust makes it practical to write a single library that can be efficiently embedded in multiple runtime environments. One probably wouldn't want to use a Go library, for example, in a C, Java, or Python project, even though it's possible with cgo. Of course, if a Rust library is using async under the hood, it'll probably run a main loop on its own thread. But that happens often enough in C and C++ libraries as well.