explain why trio is better, preferably with "real-world" examples

[cjerdonek]

My apologies if this is already covered somewhere. But in the README, it says:

[Trio's] resulting design is radically simpler than older competitors like asyncio and Twisted, yet just as capable.

Perusing the docs, though, I can't seem to find any examples explaining why this is the case.

I think it would be helpful if somewhere in the docs you could show why trio is better using concrete examples. Perhaps you could take a couple use cases and then implement them in both trio and asyncio (and Twisted?), and then explain why the trio implementation is simpler, or better, etc.

Also, it would be good to be honest. What does someone give up by choosing trio over asyncio.

Finally, what's involved in transitioning to and from trio? Wholesale rewrite? Can one transition incrementally, etc?

[cjerdonek]

I just saw issue #132, so I guess this is a duplicate.

[njsmith]

You're right, it would be good to have more details here.

Briefly in the meantime:

I can't seem to find any examples explaining why this is the case.

It actually hadn't occurred to me that this part might be controversial :-). Obviously side-by-side comparison is great, but even twisted and asyncio's biggest fans will agree that approachability is not their strongest suit.

Perhaps you could take a couple use cases and then implement them in both trio and asyncio (and Twisted?), and then explain why the trio implementation is simpler, or better, etc.

The first part of this blog post is exactly that; it uses curio instead of trio for the comparison, but trio is basically designed as a next-generation curio.

I've also been thinking that "happy eyeballs" would be a good example for another blog post, since it's a small but real and decidedly non-trivial problem where I can't be accused of cherry picking. (Trio's implementation is in #145; twisted's is in their HostnameEndpoint, though their current version is generally agreed to be very hard to understand so there's also a branch where glyph is working on rewriting it. AFAIK no one has yet implemented this for asyncio: python/asyncio#86)

Also, it would be good to be honest. What does someone give up by choosing trio over asyncio.

Mainly the community and library ecosystem (at least for now). Though this is also what you give up choosing asyncio over twisted :-).

Finally, what's involved in transitioning to and from trio? Wholesale rewrite? Can one transition incrementally, etc?

Currently there isn't any particular interoperability story, though see #171 for some notes on how we could fix that.

[cjerdonek]

Thanks for the explanation. I should have read the blog post again after becoming more familiar with asyncio. The blog post is quite long, so perhaps some bullet points summarizing the differences in addition to a link and examples would suffice.

Also, since it looks like asyncio will be acquiring run() and friends (and which can be mitigated in the meantime with documentation of the recommended boilerplate), I think it would be best to focus on comparing Trio to asyncio with "pure" async/await. Another aspect of the comparison is whether the differences are due to fundamental aspects of asyncio or simply bugs or missing functionality (which can in theory be fixed).

[njsmith]

I think it would be best to focus on comparing Trio to asyncio with "pure" async/await. Another aspect of the comparison is whether the differences are due to fundamental aspects of asyncio or simply bugs or missing functionality (which can in theory be fixed).

s/trio/curio/ and you have exactly described what that blog post is about, especially the "is this fixable" part :-). My conclusion is that when you layer async/await on top of callbacks and protocols then the abstraction leaks a lot and this isn't really avoidable.

And AFAIK the planned asyncio changes don't really affect much -- the new thread-local loop tracking is a great feature that solves one of the problems I noted, but it's really the least essential problem. asyncio.run isn't a replacement for curio.run/trio.run, because the key feature of the latter is that they have a general strategy for detecting when your whole program has finished, whereas in asyncio you still have to manually keep track of the lifetime of all connections to figure out when it's safe to shut down the loop. (And asyncio.run_until_complete doesn't really solve this -- it waits for that coroutine to finish, but if there are Tasks still running then they just get unceremoniously abandoned. That can't happen in curio/trio.)

(Heck, in asyncio if you're using the high-level async/await-oriented functions like open_connection and start_server, and you have a protocol where you speak last, like an HTTP server, then it's actually impossible to deterministically do a graceful shutdown that doesn't risk truncating connections, because there's no way to know when asyncio has finished draining your connection's send buffer and its safe to exit. This particular bug is fixable, but it's an example of how tricky asyncio makes lifetime management that there's this fundamental a bug in the core code. This class of bug can't happen in curio/trio.)

Anyway, I'm definitely not saying that that blog post is the best possible documentation, and I appreciate the suggestions. This is a huge area, different people find different aspects compelling, ... improving the docs/marketing/communication-in-general is an ongoing process :-). So this kind of feedback is very much appreciated -- I'm just trying to give some quick hints as to what the proper documentation might eventually say so that you don't have to wait that long :-).

[cjerdonek]

Cool, I appreciate this summary, and keep up the interesting work!