39 ms·

Wow, this is really helpful and timely! I'm building a new language with async/await and had to make a lot of these decisions, but I didn't have this organized

Wow, this is really helpful and timely! I'm building a new language with async/await and had to make a lot of these decisions, but I didn't have this organized of a framework to ground myself in. I'm happy to see it clearly that I choose mostly Trio with a bit of JavaScript. My language (Zena's) async docs page: https://zena-lang.dev/guide/async/ https://zena-lang.dev/guide/async/ I think I might do a pass and try to call out the decision points more explicitly. fwiw, I found this post on cancellation by the author of Trio to be vey compelling: https://vorpus.org/blog/timeouts-and-cancellation-for-humans/ https://vorpus.org/blog/timeouts-and-cancellation-for-humans... and I based the cancellation design of Zena on it. Edit to add: I do wish this included JavaScript's AbortSignal in the Cancellation section. Not because it's good, but because passing cancel tokens is a pattern that exists. There's also the dimension of who can cancel and, like AbortSignal, whether tasks have to opt-in to cancellation checks.

bufordsharkley 5d ago
I definitely find trio (formerly curio) to be so thoughtfully designed at every turn; it's dispiriting that it never seemed to gain much of a user share over asyncio (whose main advantage appears to simply be inertia and stdlib privilege)
jeremyjh 5d ago
Since this exercise was pseudo-code, I did not think particularly hard about the semantics of specific implementations, I just reasoned about what I would naively expect from any implementation. The answer I gave was the Trio answer - this was the first time I heard about Trio. I realized I have very little experience with async/await; I've only used it extensively in Javascript and only in the browser there - so if my understanding of the exercise hinged on semantics of child_process.spawn then I had no reference point at all for that. The languages that I have used extensively for back-end work either have native green-threads (Elixir, Haskell), or further back in my career I simply used synchronous I/O in Java and C# which only offered async or futures long after I'd moved on from them. Frankly, this is a big part of why I chose Elixir and Haskell (and lately, some Go). edit: Also thanks for your work on Zena, and mentioning it here! I've looked for exactly this before. Now I just have to invent a project for it :)

bufordsharkley 5d ago

I definitely find trio (formerly curio) to be so thoughtfully designed at every turn; it's dispiriting that it never seemed to gain much of a user share over asyncio (whose main advantage appears to simply be inertia and stdlib privilege)

jeremyjh 5d ago

Since this exercise was pseudo-code, I did not think particularly hard about the semantics of specific implementations, I just reasoned about what I would naively expect from any implementation. The answer I gave was the Trio answer - this was the first time I heard about Trio. I realized I have very little experience with async/await; I've only used it extensively in Javascript and only in the browser there - so if my understanding of the exercise hinged on semantics of child_process.spawn then I had no reference point at all for that. The languages that I have used extensively for back-end work either have native green-threads (Elixir, Haskell), or further back in my career I simply used synchronous I/O in Java and C# which only offered async or futures long after I'd moved on from them. Frankly, this is a big part of why I chose Elixir and Haskell (and lately, some Go). edit: Also thanks for your work on Zena, and mentioning it here! I've looked for exactly this before. Now I just have to invent a project for it :)