3 ms·
I'd be curious to see this benchmarked against Tornado, Twisted, gevent w/ Flask, and Node.js. Would be fun to see where it fit into the possibilities for the p
by mcescalante 12y ago
I'd be curious to see this benchmarked against Tornado, Twisted, gevent w/ Flask, and Node.js. Would be fun to see where it fit into the possibilities for the popular frameworks for writing realtime web stuff.
I'm starting to write a realtime backend right now in Golang and am excited to see how it goes. Really enjoying concurrency with Go so far. Would be glad to hear anybodies opinions that have done any realtime backends in Go :)
- joshbaptiste 12y agoThis was a famous but now dated (2009) socket benchmark of frameworks that involved Diesel http://nichol.as/asynchronous-servers-in-python http://nichol.as/asynchronous-servers-in-python
- rdtsc 12y agoI wouldn't look at that. That is 5 years old, and that was a different Diesel framework. Ok, same name (a cool one, I must admit), and I think same group of people. But, it did concurrency differently. It used to be a yield based API. Which, funny enough, is like Guido's latest Tulip/Async.IO approach. And it seems me they (Diesel) decided against it, and I 100% agree. Having yields in the library code, aside from demos and small examples, doesn't work very well. I think Diesel creators came to their approach from a practical standpoint. And I think Guido (and other proponents of async yield based IO) came from a purist/theoretical approach. We'll see what will happen in the future. It is hard to tell. But I don't see yields everywhere as a good thing. Just like I don't see callbacks or deferreds everywhere as a good way to do concurrency. greenlet (the base module gevent and eventlet are based on it) is probably the best thing that happened to Python in its recent history. It is really unfortunate it wasn't adopted as the main concurrency mechanism in the latest version.
- fzzzy 12y ago"yield from" isn't available on Python 2.7, maybe that's why they switched?
- jamwt 12y agoThat would have helped a lot, yeah. Also, dealing with exceptions in an intuitive way when you have a "fake" stack you're managing yourself is a drag. The performance of of managing your own stack also sucks. But probably the biggest practical issue is there is a terrible, common silent mistake pattern, that bit us over and over again: self.do_something_async() # it's a generator What you really wanted to do was to `yield` this so the reactorish element in the frame above you consumes it. Instead, you created a NOOP generator that is never consumed, so whatever work you thought you did, silently.. does nothing. Anyway, I think `yield from` helps you get around some of this stuff, but I haven't been keeping up with tulip. Which is probably kind of silly since Guido works like 50 feet away from me. Btw, hi Donovan. :-)
- zaius 12y agoWhat was tulip (and is now asyncio in 3.4) has a debug flag that you can enable to detect if a coroutine is scheduled but never called. More info here: https://docs.python.org/3/library/asyncio-dev.html#detect-coroutine-objects-never-scheduled https://docs.python.org/3/library/asyncio-dev.html#detect-co...
- fzzzy 12y agoThanks for the tip, that's really useful info.
- fzzzy 12y agoHi Jamie. That's some really interesting insight, thanks! I'm toying with generators in javascript now and I can see forgetting the yield being an issue. The other reply to your comment seems to suggest there is a solution though, I'll have to look into that. Greenlet giving great exception stacks sure is nice, and greenlet's performance is REALLY nice. (Can you believe it has been almost 10 years??)