Trio: Add a section in readme comparing trio to tornado/twisted/asyncio/curio

[sametmax]

Investing in a async tech has a cost. You should write a few words to let us know why we should consider your tech instead of:

• twisted/tornado that are considered mature and battle tested
• asyncio which comes with the stdlib
• curio which is the currently popular outsider

[njsmith]

There used to be a few words about this in the README, but I took them out b/c people were complaining they wanted to get directly to the meat and skip all the words :-) If you're curious: https://github.com/python-trio/trio/blob/5e661a21931009de6bb4e1247dca741f4bf2dcd0/README.rst

I'll hopefully have a chance to write up a definitive answer to this soon, but in the mean time the short version is that callback-based libraries like asyncio/twisted/tornado are inherently difficult to use correctly when compared to async/await-based libraries like curio/trio. Curio and trio are much more similar to each other; basically the difference between them is that curio exists because Dave dislikes asyncio and wants a sandbox to explore alternatives, while trio exists because I dislike asyncio and want to have something I can use to build and ship stuff. (Until I split off to write trio, I think I was the 2nd most active curio contributor after Dave? and that blog post I wrote was a major factor in curio's popularization; trio is very strongly influenced by both the awesome ideas in curio and also the places where I felt it had weaknesses. The two projects remain on good terms :-).)

Guido's actually said that he'd like to see a curio/trio-style library added to the stdlib in 3.7 or 3.8... I'm not entirely sure I agree (for the usual reasons why adding stuff to the stdlib is a complicated trade-off – "the standard library is where modules go to die" etc.), but if we are going to do that then trio is basically my proposal for what it should look like.

[sametmax]

Cool. Also:

• is trio using the asyncio event loop ?
• can it currently be used in a program using already the asyncio event loop ?
• if no will it allow it in the future ?

[njsmith]

No to all of those questions. Again, this blog post explains why: it's basically impossible to build a library like curio/trio on top of asyncio. The underlying abstractions are too leaky.

It is possible/likely that we'll have some kind of interoperability support in the future, e.g. by running asyncio in one thread and trio in another and providing some convenient tools for the two worlds to talk to each other. (Curio has been experimenting with something like this recently.) But this is always going to be a bit of a hack at best – fine as a temporary measure, but not really anyone's preferred way of doing things.

[sametmax]

So basically, if I want to make an async web framework, I had the choice between asyncore, tornado, twisted and gevent. All of them incompatible. Then came asyncio. Now I have curio and trio. And if I choose wrong I'm stuck with it, on a little island of incompatible IO API. After all, you can create a lib to like h2 to be independent from IO, but not a whole framework.

I like diversity in FOSS, but JS and C# have imperfect solutions running fine so they can concentrate on building stuff on top of it.

I feel it's like the DE in linux. On windows and mac, there is one imperfect DE and people just build apps for them and don't bother. In linux, you have many, many choices. And as a results, building anything with custom windows decoration, system tray, deep DE workflow integration, etc. rarely happens because you have too many targets. People have said many time "then just build for one" or "having many choices don't remove your freedom" and the like but in practice, anybody building an app on linux knows the pain. Even targetting the most popular solution just became a loosing move since Ubuntu dropped unity.

I'm really afraid that we will see the same happening with async on Python. From not enough good solutions to too many solutions so eventually no essential high level tooling will exist.

It's not a rant against your work, I think your concept is very interesting. But I wonder if it's not just giving in to the XKCD standard syndrom.

How do you plan to make trio so good and so widly available that it will help more than it hurts ?

[alekibango]

@sametmax i hear you, and i share the same pain.

The pain you feel is from using 'bleeding edge' stuff and ideas. I prefer this. Safe spaces (approved by leftist government) are not for me. I am very gratefull for alternatives, and i learned much from them. Even if i didnt use trio (yet), it was very good for me to learn some ideas from it.

[njsmith]

@alekibango I'm not sure what you think "safe space" means or why you're injecting comments about governments into a discussion about async library ecosystems, but please do review our code of conduct.

@sametmax Sorry I lost track of this question. To answer briefly and belatedly: You're right that splitting the ecosystem is a serious thing to do, and I thought hard before starting trio for this reason. It's a valid question. But hopefully from a year later it's clearer why I did it: trio's a fundamentally new and different approach, and the productivity benefits IME are large enough that trio has some chance of becoming the de facto standard (e.g., the 40 line happy eyeballs). I've taken this seriously from the start, and tried to grow a project and community commensurate with that task. Of course it's also possible that it won't – but if so the project still won't have been a waste, because we've been learning a tremendous amount about what it takes to make trio's theoretical ideas work in a real, practical system – things we couldn't have learned without actually doing it! – and now other projects like asyncio are studying us to learn from that experience. And in the mean time, the trio community tries to contribute back to the larger python async ecosystem wherever possible (e.g. async_generator, sphinxcontrib-trio, h11, ...), and we're working on projects to directly bridge the gap like trio-asyncio, sniffio, adding support for multiple async backends to urllib3...

Is that enough that we help more than we hurt? Well, I've done my best to make sure it is, but you'll have to judge for yourself.

[alekibango]

@njsmith, i am sorry if i sounded wrong.

Freedom to think and to search for happinness always leads to mupltiple paths. It is inevitable. All those new asyncio libraries are still somewhat 'bleeding edge' for general public. Living on the edge means living a dangerous and/or unusual everyday life.

Safe spaces on the other hand are by definition without new/dangerous/conflicting ideas. But real progress is impossible without some level of freedom, conflict and its resolution.

I really meant to say something like this: "I would love you to embrace the nature of living on the edge. It hurts, yes. Train hard, never quit. Fight the chaos and win. For you and for all of us. It is worth it. If we all used only one coding language and its standard library, life would be no fun. Both curio and trio helped me a lot! They surely didnt hurt me."

[njsmith]

@Fuyukai Thanks.

@alekibango There's something exciting about the vision of new ideas coming out of violent struggle, isn't there? It's like the slogans in Nike ads – that stuff sells! But it doesn't match my experience. "Safe spaces" were invented as a tool for radical political organizing around issues like women's and LGBT rights. Developing new ways of thinking is difficult, especially when they go against the mainstream; new ideas start out fragile and flawed and need space to grow up a bit before they can be properly evaluated. It's like starting out new seedlings in a greenhouse so they can grow up a bit before being exposed to the outside weather.

I appreciate your enthusiasm, but Trio started as a project to distract me when I was sick and exhausted; if it had hurt, if I had to "train hard", "fight the chaos", then it wouldn't exist, because I just didn't (and don't) have the energy. The reason it exists as a separate project from asyncio, with a strong code of conduct and contributor guidelines, is exactly because its ideas need a safe space for experimentation and learning to happen. There's no war between trio and asyncio – in fact, I'm sitting next to the lead maintainers for asyncio and aiohttp right now; we're all working on the same problems, and learning from each other as we go. It's possible to engage with complex and controversial issues in a humane and thoughtful way; in fact, it's the only way the really works.

Anyway, this is getting way off-topic, so let's let this thread end here.