Skip to content

Instantly share code, notes, and snippets.

@jashkenas
Created June 29, 2010 00:35
Show Gist options
  • Save jashkenas/456608 to your computer and use it in GitHub Desktop.
Save jashkenas/456608 to your computer and use it in GitHub Desktop.
[02:38] jashkenas: ryah: if you're around now, I'd be very curious to hear your thoughts on Steve Dekorte's comparison of a Node.js/callback proxy versus an Io/coros proxy:
[02:38] jashkenas: Node: http://www.iolanguage.com/paste/p/f05588fa6.html
[02:38] jashkenas: Io: http://www.iolanguage.com/paste/p/2f7b5fce1.html
[02:39] maqr: jashkenas: my plan is to make a little tool for tumblr theme developers to push up their latest work, rather than having to use tumblr's web interface, if you were wondering :)
[02:39] mjr_: I noticed that one has fewer lines.
[02:39] jashkenas: maqr: fun.
[02:39] maqr: ryah: oh ok, all the buzz i hear is about how it's X times faster than a normal webserver
[02:39] maqr: and i'm not sure what "evented I/O for V8" really means yet :)
[02:40] jashkenas: mjr_: I think that the question is more about whether we're comfortable and settled on writing out the explicit callback form, longhand. Or if it seems like there's room for improvement with this example (coros or not).
[02:40] Tim_Smart: jashkenas: I would have thought you could just set up a sys.pump to create a good proxy
[02:41] mjr_: maqr: the phrase "evented IO for V8 JavaScript" is what got me involved, but I agree that it can be a bit opaque if you don't know why that combination of things is interesting.
[02:41] ryah: maqr: that's okay. mostly it's in development - but 6 months from now hopefully node will be a good choice for end users
[02:41] maqr: sounds like a good place to jump in then :)
[02:41] jashkenas: Tim_Smart: is sys.pump documented yet?
[02:41] maqr: i'd say i "know" js, but i've only ever used it inside the web browser
[02:42] ryah: maqr: that said, i think node is the only ssjs project worth pursing right now
[02:42] Tim_Smart: jashkenas: Nope. But it documents itself particularly well: http://github.com/ry/node/blob/master/lib/sys.js#L286-302
[02:43] Tim_Smart: Actually, it could might as well be.
[02:43] maqr: ryah: it's odd, because other languages seem to have the web tacked on later... but with javascript, i didn't even know that one could require() until i started reading the node.js docs, and i never thought of it in any standalone way
[02:43] ryah: jashkenas: two different styles to writing evented code
[02:43] maqr: ryah: unless the 'ss' in 'ssjs' really just means "will run outside of a web browser"
[02:44] ryah: jashkenas: one is 'javascripty' and simple
[02:44] steadicat has joined the channel
[02:44] ryah: the other is not javascripty and involves context switching
[02:44] zenom_: since I cannot do an ajax request across ports it appears, how do you guys suggest me getting my data to a ruby app that is being pulled from a node.js (twitter updates is the data in json format)
[02:44] jashkenas: ryah: so you're comfortable with the difference -- that's encouraging to hear. thanks.
[02:45] ryah: i'm fairly convinced combining cooperative threads with events is a horrible choice - it should be one or the other
[02:46] ryah: hence node will never have it
[02:46] kriszyp_ has joined the channel
[02:47] ryah: because it's too difficult to keep track of yields. complicates programming model
[02:48] ryah: (note: node used to have "promises" which could "wait()" for completion - it was awful and i removed it because of the bug it led to)
[02:48] ryah: (the implementation was also really bad - but that wasn't why it was removed)
[02:50] ryah: if you have coroutines with tcp sockets that emit 'data' events (instead of looping and doing a blocking read()), you need to be very very careful everytime you call a function
[02:50] ryah: because that function might yield
[02:50] ryah: somewhere very high up in the callstack even - in some 3rd party module
[02:50] ryah: and you get context switched out
[02:50] ryah: then your back on the event loop
[02:50] ryah: and you might, for example, recieve another 'data' event
[02:51] ryah: and now you re-enter the same callback before the previous one had completed
[02:51] ryah: this requires explicit locking for a lot of states
[02:51] Tim_Smart: and locking is annoying
[02:51] jashkenas: sure. that all makes sense implementation-wise. threads are threads are threads.
[02:51] jashkenas: I was wondering from more of an aesthetic perspective ...
[02:52] ryah: jashkenas: i find the event model reflect reality
[02:52] ryah: one process - one thread
[02:52] ryah: sorry, i find the event model reflects reality better
[02:53] ryah: and i think in complex I/O systems the event model is easier to work with
[02:53] ryah: because in the end - the compter is evented
[02:54] ryah: there isn't something sitting in a loop polling a socket ofr new data
[02:54] ryah: doing a blocking read()
[02:54] jashkenas: that's a nice argument -- from first principles.
[02:54] ryah: data arrives
[02:54] ryah: you handle it
[02:54] ryah: there are all these layers that try to simplify this reality
[02:54] Tim_Smart: jashkenas: I also found his javascript example seems to as bloated as possible
[02:54] Tim_Smart: jashkenas: I'll see if I can re-write it
[02:54] ryah: and that is largely why software sucks
[02:54] jashkenas: ryah: you might want to add some of these thoughts to your node.js/#about section. It talks about servers and speed, but talking about events as reflecting the reality of the computation is a nice way to think about it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment