[frognibble]

Tornado solves the problem of building web frontends, particularly those with comet features. This problem is not specific to FriendFeed. A number of other services use Tornado including Brizzly, Quora and Hipmunk.

Twisted has support for many network protocols while Tornado only has support for HTTP (client and server). If you are doing something other than HTTP, than Twisted might be the better choice.

[Locke1689]

The author mentions how he switched from using Twisted to Node.js. I would be very interested in hearing more about the advantages and disadvantages of this as I am building a service in Python right now that I am using Twisted for. I don't really know anything about Node.js but I have been hearing a lot about it. A couple hangups for me are that 1) I'm not a huge fan of Javascript itself and 2) I'd really rather not mix Python and Javascript together. Note that my app doesn't currently use HTTP and maybe that plays a role in Node vs Twisted.

[dlsspy]

I argue that twisted is better for most practical uses of comet.

Tornado mastered only the "have lots of suspended connections" thing. Many of the examples involve blocking for processing one of those connections. What's the point of having 20k connections terminated on an http comet connection if you completely block the entire event loop to service a single one while you make another network connection (e.g. memcached, mysql, etc...).

In this regard, most real life comet apps are doing more than http. To be fair, tornado did ship with a yet another python http client, so you can at least use it with a database that speaks http without blocking, though without chainable deferreds, it's hard to do the exact right continuations required to chain these events together without locking the event loop.

[frognibble]

The Tornado philosophy is to use blocking for fast operations and async for the occasional long operation. Tornado applications compensate for blocking by running several instances of the application.

Twisted is theoretically better than Tornado because everything is async in Twisted, but Tornado is more practical because it's easier to write straight-line code than chains of callbacks. The cost of Tornado is that you need more memory on the frontend because you run more instances of the application.

In my previous comment, I listed some real life comet applications that use Tornado. What real life comet applications use Twisted?

[dlsspy]

@inlineCallbacks make linear code very easy to write in twisted. Have you tried it lately? Here's a snippet of code out of my gearman implementation:

    @defer.inlineCallbacks
    def gclient(gearman):
        w = client.GearmanClient(gearman)
        x = yield w.submit('test', 'some data')
        print "result:", repr(x)

Pretty straighforward, I think -- you just stick a 'yield' between your invocation and the capture of the results.

As far as who's using in actual comet applications -- it's hard to say. The last time I tried looking for a comet implementation, what appeared to be the canonical "cometd" was written in twisted. I ended up not using it and rolled my own twisted based server that was closer to my requirements. It's been in production for a few years now, but is still a somewhat secret project.

I'm pretty sure you could research their userbase as well as I could.

I'm not saying twisted is perfect and all other technology sucks (though deferreds, once you understand them, are really the only way to do this sort of thing).

When tornado was launched, I started playing with it and couldn't understand why it prevented me from integrating so many asynchronous tasks. I spent an hour or two separating the good parts of tornado from the reimplementation of twisted and built tornado on top of twisted. It was, as far as I could tell, at the starting point, minus 1,297 lines of python.