Hacker Newsnew | comments | show | ask | jobs | submit login

I kinda like the em-synchrony for Ruby. It handles the callbacks with fibers, so my actual code doesn't have the callback hell of Javascript. Although the implementation of Ruby fibers is not-so-nice at this point. I hope they'll fix it in the next versions.



em-synchrony's problem is it has people wrap asynchronous libraries one-at-a-time. There's a few problems with that:

You're exposing a synchronous API, but still can't take advantage of the huge ecosystem of Ruby libraries that already expose synchronous APIs.

Wrapping libraries becomes a one-off chore. Each individual library must be wrapped to work in an em-synchrony system, and if the libraries aren't both asynchronous and wrapped in fibers you can't use them. This not only shrinks the ecosystem of libraries further, but is also more error-prone than providing a general coroutine abstraction around socket IO.

Providing a generalized abstraction for doing synchronous I/O with sockets/fibers and an evented backend is exactly what I'm working on in Celluloid::IO:

https://github.com/tarcieri/celluloid-io

-----


This is a very interesting project. I'll have to dig deeper into it soon.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: