Where I come from: I am the main author of the trio. I am also one of the main contributors to curio (and wrote an article about this that you are referring to), and the Python developer core, which has been actively involved in discussing how to improve asynchrony.
I'm not sure what you mean for callbacks. In a trio (and curio), one of the basic design principles is that you never program with callbacks; it is more like streaming programming than callback programming. I think if you open the hood and see how they are implemented domestically, that is, places where they use callbacks or things that are equivalent to callbacks if you squinted. But it looks like Python and C are equivalent, because the Python interpreter is implemented in C. You never use callbacks.
Anyway:
Trio vs Asynchronous
Asyncio more mature
The first big difference is the maturity of the ecosystem. While I'm writing this in March 2018 , there are many more libraries with asyncio support besides trio support. For example, there are currently no real HTTP servers with trio support. The Framework :: AsyncIO classifier on PyPI currently has 122 libraries, and the Framework :: Trio classifier has only 8. I hope this part of the answer gets outdated quickly - for example, here Kenneth Reitz is experimenting with adding trio support in the next version of queries - but right now you should expect that if you are a trio for something complicated, then you will come across the missing parts that you need to fill out yourself instead of grabbing the library from pypi, or that you will need to use the trio-asyncio package, which allows you to use libraries induction in the Trio program . (The trio chat channel is useful for figuring out what is available and what other people are working on.)
Trio makes your code easier
In terms of real libraries, they are also very different. The main argument for the trio is that it makes writing parallel code much easier than using asyncio. Of course, when was the last time you heard someone say that their library makes it difficult to use ... let me give you a concrete example. In this talk ( slides ), I use an example implementing RFC 8305 "Happy Eyeballs" , which is a simple parallel algorithm used to efficiently establish a network connection. This is what Glyph has been thinking about for many years, and its latest version for Twisted is ~ 600 lines. (Asyncio will be roughly the same: Twisted and asyncio are very similar in architecture). In a conversation, I teach you everything you need to know in order to implement it in <40 lines using a trio (and we will fix the error in its version while we are on it). Thus, in this example, using a trio literally simplifies our code by an order of magnitude.
You can also find these comments from interesting users: 1 , 2 , 3
There are many differences in the details.
Why is this happening? This is a much longer answer :-). I am gradually working on writing different parts in blog posts and conversations, and I will try to remember to update this answer with links as they appear. In principle, this boils down to the fact that Trio has a small set of carefully designed primitives that have several fundamental differences from any other library that I know (although, of course, are based on ideas from many places). Here are some random notes to give you some ideas:
The very, very common problem in asyncio and its related libraries is that you call some_function() and it returns, so you think it is done, but it actually still works in the background. This leads to all complex errors, because it makes it difficult to control the order in which events occur, or knows when something really ended, and it can directly hide problems, because if the background task crashes with an unhandled exception, asyncio will usually just be Type something on the console, and then continue driving. In a trio, how we handle the spawning task with the help of “nurseries” means that none of this happens: when the function returns, you know that it is done, and the trio is currently the only concurrency library for Python where exceptions are always spread until you catch them.
The three-way way to manage timeouts and cancellations is new, and I think it's better than previous modern systems like C # and Golang. I really wrote a whole essay about this, so I will not go into details here. But an asynchronous cancellation system - or indeed, a system that has two of them with slightly different semantics, is based on an older set of ideas than even C # and Golang, and it's hard to use them correctly. (For example, it is easy for a code to accidentally “avoid” cancellations by creating a background job, see the previous paragraph.)
There are many unnecessary things in asyncio that can make it difficult to determine what to use when . You have futures, tasks, and coroutines that are mainly used for one purpose, but you need to know the differences between them. If you want to implement a network protocol, you need to choose whether to use the protocol / transport layer or the stream layer, and both of them have complex errors (this is the first part of the essay related to you ).
The trio is currently the only concurrency library for Python where control-C works as you expect (i.e. raises KeyboardInterrupt anywhere your code is). This is a trifle, but it matters a lot :-). For various reasons, I do not think this can be fixed in asyncio.
Summarizing
If you need to send something to production next week, then you should use asincio (or Twisted or Tornado or gevent, which are even more mature). They have large ecosystems, other people used them in production before you, and they do not go anywhere.
If you try to use these frameworks, you are disappointed and confused, or if you want to experiment with another way of doing things, then be sure to check out the trio - we are friendly :-).
If you want to send something to production in a year ... then I'm not sure what to tell you. Python concurrency is in a thread. A trio has many design-level advantages, but is that enough to overcome an asynchronous start? Will an asinchoo in a standard library be an advantage or a disadvantage? (Note that nowadays everyone uses requests , although the standard library has urllib .) How many of the new ideas in the trio can be added to asyncio? No one knows. I expect there will be many interesting discussions at PyCon this year :-).