diesel

This is old. Is it still maintained after Google acquired Bump? Not much recent activity: https://github.com/jamwt/diesel/graphs/contributors

No Python3? I can't really find anything on supported versions. EDIT: Looks like it's only for >=2.6 https://github.com/jamwt/diesel/blob/master/setup.py#L3 That's unfortunate because I need a clean event framework for Python3.

I added an implementation [1] in diesel [2][3], which uses select.epoll (or libev, on non-Linux systems) and got a around 150x speedup [4]. I only repeated the tests a few times (but they were all close) and didn't install the Go compiler so I could test against Go (I'd be interested to see how this stacks up on your machine). Like you say in your post, it's nice to have something wrap up the bother of epoll for you. [1] https://github.com/wmoss/Key-Value-Polyglot [2] diesel.io [3] https://github.com/jamwt/diesel [4] The first run is against the diesel one wmoss@wmoss-mba:~/etc/Key-Value-Polyglot$ time python test.py real 0m0.134s user 0m0.040s sys 0m0.020s wmoss@wmoss-mba:~/etc/Key-Value-Polyglot$ time python test.py real 0m20.164s user 0m0.096s sys 0m0.072s

I've taken quite a deep look at it: https://github.com/jamwt/diesel/blame/e360313d3950a952110b1d...

> python you can trick generators into turning synchronous-looking code into asynchronous Example: http://dieselweb.org/lib/ or https://github.com/saucelabs/monocle Although Diesel2 is much more interesting, with greenlets support. No more messing about with `yield`, since the blocking functions themselves force a context switch. https://github.com/jamwt/diesel

This may be just my impression, but if someone really had a need for an async server, they wrote it in something else before. I'm not saying node.js is bad in any way, but there are more established alternatives in languages people already use. They were used before and they did the job. Is node.js going to be a temporary thing?... we'll see. Is it that different from what we already had? (compare http://github.com/jamwt/diesel/blob/master/examples/http.py and http://nodejs.org/api.html#synopsis-0 ) not really.

Yep, this was a big part of why I eventually abandoned generators in diesel in favor of a greenlet-based approach. http://github.com/jamwt/diesel/commit/2fc64f9d50bc6f9a5cfff0... I'd worked my way through all the problems having to do with simulating a generator-based "stack" and it was not pretty--exception handling in particular with these "fake stacks" was hard to make behave the usual pythonic way. I wasn't eager to give up on a generators, but I had to eventually concede that the practical quality of the project was more important than the founding idea. Everything has been faster, easier to program, and more stable since giving up on generators and moving to the greenlet library. At bump, we just launched version 2.0 of our app, running our backends 100% on diesel2/greenlets: http://mashable.com/2010/07/26/bump-2-0/

I'm a big fan of MongoDB, and I think its replicated durability characteristics are good enough for many classes of applications. If you could lose a minute of data and have it just be "bad" instead of "customer enraging and business threatening", then it's a very nice database system. However--I do think the decision to make writes "fire and forget" is just a mistake. If you use abstractions like a connection pool under heavy concurrency, you can get unpredictable behavior in terms of when the data is "actually there." For example, all in one thread: with connection pool: do_write operation A do other things... with connection pool: read something, assuming A has been applied Specifically, the fact that you get an arbitrary connection out of the pool means you cannot be sure that the database has completely processed operation A before