"Ruby developers need to stop using EventMachine. It's the wrong direction."

Post by draegtun » Thu, Oct 25, 2012, 8:32 AM UTC

bascule wrote: post #19

tptacek wrote: post #4

We write a lot of EventMachine code here; I have some questions. He writes: EventMachine is • A frankenstein guts the ruby internals • Not in active development • Makes non-blocking IO block • Requires special code from Ruby libraries • Hard to use in an OOP way • Is really difficult to work with • Poorly documented I'm not sure I understand how EventMachine "guts the Ruby internals" (I didn't watch the talk). It's tr…

> I'm not sure I understand how EventMachine "guts the Ruby internals" EventMachine does not use the Ruby IO primitives (e.g. TCPSocket, UDPSocket, etc) as the basis of its IO abstraction, and instead has reimplemented its own set of primitives for doing IO. Because of this it can't take advantage of work being done in Ruby core to advance Ruby's socket layer. For this reason IPv6 support langered, among other proble…

Post by lmm » Thu, Oct 25, 2012, 9:20 AM UTC

cmccabe wrote: post #39

tptacek wrote: post #10

Earlier quoted context omitted.

Real evented code isn't a series of onRead/onWrite callbacks, because real evented code buffers strategically, and abstracts itself into state machines with simple callback interfaces, so that the rest of the program can be written in terms of higher level events. I don't want to turn this into "events work for every program", because like I said above: I don't think event interfaces work for all kinds of programs. I…

I don't see the "evented runtime vs. evented API" issue as boring. This kind of thing is the core of any application you are going to build; it's hardly a minor or nitpicky issue. Using non-blocking APIs requires you to turn your application "inside out", putting state that would normally have been on the stack into a state machine. You wind up in a maze of callbacks and low-level details. This kind of thing might be…

Post by robotmay » Thu, Oct 25, 2012, 9:39 AM UTC

bascule wrote: post #16

danielszm wrote: post #5

Earlier quoted context omitted.

I wonder why nobody ever talks about drb, a distributed system that ships with ruby. It's active in Japan, and there has been an effort to make it better known in the rest of the world with a book dedicated to the topic in english (published by Pragmatic Programmers). Still, it hasn't stirred much interest. Even if it's less advanced than DCell, it's still a recommended way to start learning about distributed computi…

Hello, author of Celluloid here. I think DRb pretty cool and has long been underutilized. That said, there are a few fundamental design problems with the way it works that I think DCell solves: 1. Distributed systems really need to be built on top of asynchronous protocols, and DRb is a direct mapping of a synchronous method dispatch protocol onto a distributed systems protocol. Similar attempts at this include: CORB…

Post by cdavid » Thu, Oct 25, 2012, 11:47 AM UTC

bascule wrote: post #19

tptacek wrote: post #4

We write a lot of EventMachine code here; I have some questions. He writes: EventMachine is • A frankenstein guts the ruby internals • Not in active development • Makes non-blocking IO block • Requires special code from Ruby libraries • Hard to use in an OOP way • Is really difficult to work with • Poorly documented I'm not sure I understand how EventMachine "guts the Ruby internals" (I didn't watch the talk). It's tr…

> I'm not sure I understand how EventMachine "guts the Ruby internals" EventMachine does not use the Ruby IO primitives (e.g. TCPSocket, UDPSocket, etc) as the basis of its IO abstraction, and instead has reimplemented its own set of primitives for doing IO. Because of this it can't take advantage of work being done in Ruby core to advance Ruby's socket layer. For this reason IPv6 support langered, among other proble…

Post by debacle » Thu, Oct 25, 2012, 12:54 PM UTC

jeremyjh wrote: post #48

bad_user wrote: post #42

Earlier quoted context omitted.

Well actually, the JVM is probably the most potent platform when it comes to async I/O, not only because the standard nio library and the high-level wrappers, like Netty and Mina, are very mature, but also because you can compose blocking and non-blocking pieces of functionality like you cannot do with Node / V8. Checkout Akka, it's awesome: http://akka.io/

There are very few libraries.