Every time you have to do asynchronous work, you have to mentally follow the chain of deferreds to ensure you understand exactly what code will be called at what time. Coupled with its unpythonic, deep hierarchical API, Twisted almost literally twists your code into a jumbled blob.
Unless you need the existing protocol-specific APIs twisted provides, stay far, far away. Find something more lightweight, like this, or Eventlet, or something else that lets your code remain concise and clear.
This comes from my experience writing a Twisted server for my startup, and subsequently rewriting it when the Twisted version became far too difficult and frustrating to maintain.
I'm sorry, but this post is just packed full of FUD.
I hear this all the time, "argh, Deferreds are so hard to understand," as if there's some kind of magic going on in a Deferred. Deferreds are just a way to encapsulate two callbacks, one for errors and another for successful callbacks.
If you're writing any kind of significantly complicated asynchronous process, what is the difference between following a bunch of Deferreds and following a bunch of callbacks??
Asynchronous coding is hard. There's no framework that is going to make that go away. Diesel looks nice enough, but although it shows promise, there's not enough examples of hardcore usage to make a sufficient comparison. An asynchronous IO framework that has nothing but HTTP and echo examples doesn't even scratch the surface of the kinds of apps that require the advanced asynchrony available in Twisted.
If you're writing any kind of significantly complicated asynchronous process, what is the difference between following a bunch of Deferreds and following a bunch of callbacks??
The difference is that in co-routine based code (such as concurrence or eventlet) there are no callbacks. Co-routines are all about message passing which leads to much cleaner and much less code in most applications.
It's not uncommon to see 40%+ boilerplate callback-handling code in a twisted app. Those are not needed in a coro-environment.
Asynchronous coding is hard.
Actually the established patterns for implementing asynchronous code are hard. You get to choose between threading-hell (deadlocks, races) and callback-hell (code-bloat). I have no idea why these abstractions grew so popular, my guess would be because they are "closest to the metal".
But they are not without alternatives; co-routines, actor-based concurrency and erlang exist - all of which enable fairly straightforward "Do what I mean" development.
I've been including Eventlet in a lot of my comments lately, but not because I have any affiliation with it (I don't). But it has quite literally made asynchronous coding so much easier that going back to deferreds or callbacks is a huge inconvenience.
My comments previously reflect equally on deferreds and callback-based asynchronous programming. Of course those make async programming hard.
Every time you have to do asynchronous work, you have to mentally follow the chain of deferreds to ensure you understand exactly what code will be called at what time. Coupled with its unpythonic, deep hierarchical API, Twisted almost literally twists your code into a jumbled blob.
Unless you need the existing protocol-specific APIs twisted provides, stay far, far away. Find something more lightweight, like this, or Eventlet, or something else that lets your code remain concise and clear.
This comes from my experience writing a Twisted server for my startup, and subsequently rewriting it when the Twisted version became far too difficult and frustrating to maintain.