Hi Josh, Racket has a number of powerful concurrency libraries/extensions that handle both concurrent execution of code in a single process as well as parallel execution across multiple processes/hosts. There is the "futures" library, which might be the most similar to Trio.
https://docs.racket-lang.org/reference/futures.html However, there are libraries that provide a larger lift, and are grounded in language traditions that tie back to algebras for reasoning about parallel systems. The channel library, and the code that builds on it ("places"), are examples. https://docs.racket-lang.org/reference/channel.html https://docs.racket-lang.org/guide/parallelism.html The history of formal reasoning, and implementation of, mechanisms for concurrency and parallelism go back to at least the... 70's? https://en.wikipedia.org/wiki/Communicating_sequential_processes "Structured concurrency" does not, from the link(s) provided, seem to be anything that stands out from this long tradition. (Or, if you prefer, computer scientists have been reasoning about, building systems around, and integrating into languages notions of parallelism and concurrency for roughly 40+ years.) So, personally, I would say that Racket has multiple libraries (which, because of the nature of Racket, are in some cases extensions to the base language) that implement structured concurrency. Unless I'm completely misunderstanding your post. Cheers, Matt On Mon, Oct 7, 2019 at 1:46 PM jab <jabron...@gmail.com> wrote: > Coming across > https://trio.discourse.group/t/structured-concurrency-and-delimited-continuations/ > just provoked me to search for discussion of structured concurrency in > Racket. I didn’t immediately find much.* I hope that doesn’t mean that the > interesting work that’s being discussed over in > https://trio.discourse.group/c/structured-concurrency etc. has been > largely unknown by the Racket community. Trio is having a profound impact > on the future of concurrency, not just in Python but in many other > languages. There’s even a post on Wikipedia now: > https://en.wikipedia.org/wiki/Structured_concurrency > > (For anyone new to the term, > https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ > might be the best starting point. One persuasive example shows Nathaniel > live coding a correct implementation of RFC 655 “Happy Eyeballs” in 40 > lines of Python: > https://github.com/python-trio/trio-talks/tree/master/njsmith-async-concurrency-for-mere-mortals > (For comparison, Twisted’s implementation took hundreds of lines and still > had a logic bug after years of work.) There is also some related reading in > https://github.com/python-trio/trio/wiki/Reading-list.) > > I hope this post provokes discussion of structured concurrency in Racket. > It’d be fascinating to read more of your thoughts! > > Thanks, > Josh > > * For example, Googling “structured concurrency racket” turned up mostly > just a brief mention of Racket’s custodians in the bottom-most comment on > this post: http://250bpm.com/blog:71 > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/bb36e50a-a77b-4c5b-b144-71ce647069b7%40googlegroups.com > . > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAAGM455HSfVgBcu%2B1FZc-mubYaeYEFZb1XxZo_z_sQNqRDO4XQ%40mail.gmail.com.
