

Javascript in your Erlang - jperras
http://davispj.com/2010/01/19/erlang_js_awesome.html

======
pierrefar
It's impressive that this is cutting the numbers by half or so. If this is
validated, I hope CouchDB integrates it to make the whole system much faster.

~~~
davisp
So far Windows doesn't seem to be getting the same boost, so we'll see how
things shake out. Though I'm more excited to hack in some other code I've
already written which will avoid the JSON conversions all together.

------
davidw
What's the point of this, exactly? You get Javascript interpreters that Erlang
can talk to. Is the point simply to have a more widely known language as the
'scripting language' for the system? Because otherwise it would just make more
sense to not bother, or perhaps even to use something like node.js directly
and cut out the Erlang middle-man. But I admittedly know little about the
situation, so perhaps someone can shed more light on it.

~~~
davisp
The reason we use an embedded scripting environment is so that the control can
be handled by Erlang. Its quite true that we could have an external system
doing Map/Reduce a la CouchDB-Lucene but that would just increase the pain
point, plus make things even harder to move between systems due to
configuration overhead etc.

Though the point of this post was mostly to play with the new erlang_js
package as well as try and determine what cost is associated with the stdio
communication channel used by the current view generation model.

