[marktangotango]

Two things;

The big HUGE win for lua in this, in my view, is the plethora of packages on luarocks. With simple scripts, as presented in this blog posts, sure a javascript subset is fine. But suppose you want to interact with redis from your script? Where's the c ffi interface, and a prepared package you can use from nginscript? Grap hiredis bindings from luarocks, and your set.

Second, great yet another javascript implementation. They're very open about supporting a subset out of the gate, who knows how long it would take to reach parity with es 5 or 6 even?

[neomantra]

I agree with what you said -- although the node/npm ecosystem is much bigger. I'm not sure how it works with the nginScript subset.

But network-related libraries shouldn't be pulled from luarocks (unless maybe they have resty in the name). One would want to use lua-resty-redis and not hiredis within OpenResty. The 'resty' libs use the nginx cosocket library so work asyncronously with nginx core. hiredis would block the worker threads.

[marktangotango]

Ah thanks, I was not aware of that. Also, unless they code nginscript to specifically support googles V8 api, there's no reason to expect node or any of it's packages to work with it.

[bungle]

Not asynchronously, but in a non-blocking fashion. Good thing is that Lua socket and ngx.tcp are quite compatible. But C libs with their own IO are - well they work, but they will block the nginx workers.

[bigtunacan]

I think this depends on just how compatible NginScript is with JavaScript. Will it be possible to pull in the ffi node module, or one of the many node redis modules?