3 ms·

I think you may be talking past each other. If 100% of integration with the system consists of sending network requests to it and receiving network responses f

I think you may be talking past each other. If 100% of integration with the system consists of sending network requests to it and receiving network responses from it, then sure, it's not going to affect you much. But when your integration involves taking existing applications/libraries and having them share memory space and call into and be called by functions in Twisted, then you're looking at a different story. Asynchronous code is infectious -- unless everything in your codebase is written to be or play nice with async, you get no benefits from the async parts and in fact can often get a net harm as the async and non-async bits clash with each other.

retrogradeorbit 11y ago
This is not about async in general. This is about twisted's approach to async. For instance, there are numerous other languages that handle async elegantly and all the libraries work and there are no special snowflakes. Go comes to mind. Asyncio in python is a better answer for Python. But twisted is not asyncio. Twisted remains it's own separate thing.
- jMyles 11y ago
  > Asyncio in python is a better answer for Python. But twisted is not asyncio. To my way of thinking about these things, this is plainly a non-sequitur. Twisted and asyncio don't do, or even try to do, the same things. The only reason that they are comparable is because, for years, Python lacked adequate primitives for expressing concurrency. Thus, Twisted, and its event loop (the reactor), handle this. And it's true that the reactor may eventually be replaced by async IO. However, the core of what Twisted does (handle network (and other I/O) traffic in an elegant, adaptive, concurrent way) is not something that asyncio is designed to replicate.