3 ms·

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? Woul

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

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.