Luvit - Lua + UV + Jit = NodeJS re-implemented in Lua | Hacker News Reader

Luvit - Lua + UV + Jit = NodeJS re-implemented in Lua

lua-list.2524044.n2.nabble.com

158 pointsYakulu37 comments

OK this is really interesting because one of the obvious criticisms you can lob over at Node.js is that the nested callback program structure that Javascript forces onto you is somewhat ugly and hard for a developer coming from more traditional frameworks to reason about.

Being able to use Lua's coroutines makes this quite interesting.

https://github.com/luvit/luvit/blob/master/examples/fs-corou...

Coroutines are available in Node via the fibers package (https://github.com/laverdet/node-fibers). For benchmarks comparing performance to purely asynchronous webapps, check out the README to my Common Node project (https://github.com/olegp/common-node), which implements a number of synchronous CommonJS proposals on Node using fibers.

My opinion about the common thought saying "NodeJS forces you to code many callbacks that seem ugly" is that some people hesitate to abstract that functions.

Also take a look at OpenResty, which bundles LuaJIT for Lua/nginx-based web app development, using the nginx event loop to do async I/O:

OpenResty aims to run your server-side web app completely in the Nginx server, leveraging Nginx's event model to do non-blocking I/O not only with the HTTP clients, but also with remote backends like MySQL, PostgreSQL, Memcached, and Redis.

http://openresty.org/

Wow.

OpenResty seems to offer considerably lower app connect time compared with bare PHP in a FastCGI process manager for this "hello world" benchmark, in addition to some unbelievable throughout.

  app                GETs/sec     throughput    time to 1st byte, min/mean/max, milliseconds

  Nginx + PHP/FPM       5,941       65KB/sec    0.72 / 1.63 /  6.75
  Node 0.6.1           10,242      123KB/sec    0.08 / 0.92 / 14.24 
  OpenResty            27,924      335KB/sec    0.07 / 0.26 /  5.36

The default config for OpenResty does not even use LuaJIT.

Data rounded for easier comparisons. See the gory details at http://openresty.org/#Benchmark

Thanks for the pointer!

Dahl's original reason for preferring JS to Lua was apparently that Lua had too many blocking libraries already:

No matter what I did, someone was going to load an existing blocking Lua library in and ruin it.

Indeed, this is a problem. I've mitigated it somewhat by changing how require works (to be more node-like) and disabling the built-in I/O library. This will make most offending libraries unable to run in Luvit. Also this means I don't get the large existing community of modules either.

I understand that this project is very immature compared to Node.js, but how does it compare performance-wise?

Can modern Lua virtual machines outperform V8?

You mean how fast can it compute fib(40) without memorization? ;)

Did you mean memoization? http://en.wikipedia.org/wiki/Memoization ;)

Without memoization. Also, these benchmarks forgo tail recursion as well, which is even less forgiveable.

The only thing I see if from the official Github page : "This project is still under heavy development, but it's showing promise. In initial benchmarking with a hello world server, this is between 2 and 4 times faster than nodeJS." Memory usage should be lower too.

Indeed. In that benchmark I did, it was 2 times faster on 32-bit linux and 4 times faster on 64-bit linux. In both the Luvit version used about 40x less ram. Also startup time is much faster in Luvit. This doesn't matter as much for servers, but for embedded devices like writing webOS games for the TouchPad, it makes all the difference in the world!

Node depending on how you build it can take between 300 and 1000 ms of time and 10Mb of ram to just start up on the TouchPad. Luvit starts instantly and uses much less ram.

Larger programs are needed to see how the memory usage and performance scales with real work. That could be completely different.

Lua uses memory efficiently at scale.

I have used Lua at the command line on machines with 64GB of RAM to do ad hoc data mining that would have otherwise required several days of prep time for writing and debugging C before each run.

Using Lua, I could do things in hours that used to take overnight, or several days.

LuaJIT could do this a long time ago already http://news.ycombinator.com/item?id=1187901

Alright after some research I fould that LuaJIT is way faster than V8:

V8: node fib.js 6.40s user 0.02s system 99% cpu 6.423 total LuaJIT: ./luajit fib.lua 2.02s user 0.00s system 99% cpu 2.026 total

http://www.saltwaterc.eu/but-the-question-is-will-it-recur-p...

"I understand that this project is very immature compared to Node.js"

Good thing you added "compared" there, because I wouldn't call Node.js exactly "mature".

It's a much leaner VM and it much faster and uses less memory in all my tests. However Lua and JS aren't the same language so real applications may show something different.

What makes languages like Python so great is the stdlib that goes with them -- I hope that projects like this can help grow Lua into a more mainstream language.

Maybe this could leverage the Lua/APR binding to get a starting stdlib?. Modules like xml, crypto, base64 and memcached would round it up nicely, not sure about the IO and threading ones, perhaps those are redundant to luvit.

memcached would presumably be an issue because of it not being non blocking, so you would want a smaller subset.

Lua Rocks is quite interesting. A lot of the ground work that was done for server-side JavaScript after Node became popular already exists, as do many modules. So you "just" need to add more, not invent something spanking new.

Never mind that I don't think this will make huge inroads. The big thing about NodeJS is that it's JavaScript, so that some frontend coder could use his already existing knowledge to quickly make a high-performing web service. And it came out with just enough hype to make it popular and create a community.

Lua doesn't really have those advantages. I do like the language a lot better than the mess that's JavaScript, but if a bunch of young coders are looking at a tool to fill a gap in their tech stack, it's not that likely that they'll look for Lua, unless they're all WoW extension programmers…

[1]: http://luarocks.org/

Maybe I am biased coming from another gaming community (Facepunch / Garry's Mod) but speaking for myself (as a young coder/developer) I like Lua.

As I wrote above, I like it a lot, too. It's a very simple, clean language without any silly flourishes, a good implementation and easily added to most projects.

But in your average web shop, the chances of finding someone who has already worked with it is pretty low, whereas JavaScript itself runs at about 100%. And I firmly believe that this is the biggest reason for the popularity of NodeJS. Not the concept (cf. eventlet, EventMachine, POE etc.), but the fact that you've been offered a simple package where you don't have to learn anything really new.

Still, I'm grateful for an extended toolkit myself, and I'm looking forward to what people can do with coroutines and tables to make the programming experience more pleasant.

Interesting, also it worth mentioning ngx_lua https://github.com/chaoslawful/lua-nginx-module It's like a swiss army knife for nginx.

and also https://github.com/ezmobius/super-nginx, an even bigger Swiss Army knife.

I've looked at the lua/nginx integration a while ago, an all the examples struck me as somewhat confusing. A lot of work was done using lua as inline nginx configuration (or just normal nginx config). Mongrel2's Tir[1] looked a lot cleaner and better documented.

[1]: http://tir.mongrel2.org/

I really love how this project copies how the node require resolution works. That is by far my favorite thing about node and it lets programmers do version management and reusability really well.

It's also worth mentioning Ignacio Burgueño's LuaNode, an older project with similar goals:

https://github.com/ignacio/LuaNode

It is interesting that javascript and lua are so similar in many ways, while one was hacked together in a few weeks and the other one was carefully designed by an academic.

They both have the same root business case: make Scheme palatable to mere mortals, by adding a familiar syntax and abandonning some features: no more macros, and most data structures made mutable.

Where Lua diverges from Javascript:

* time has been taken to design it properly;

* backward compatibility has been broken more than once, to allow cleaning up design mistakes.

Also, it's not accurate to describe Lua as "designed by academinc": early developments have been driven by Petrobras' needs, more recent ones by the gaming industry and some prominent users such as Adobe's Photoshop Ligthroom. If you look at Lightroom team's rants about Lua 5.0 (http://www.lua.org/wshop05/Hamburg.pdf), then at the Lua 5.0 -> Lua 5.1 diff, you'll see that the latter is closely inspired by the former.

Traditionally in Scheme all data structures are mutable (the PLT folks made the gutsy move of making conses immutable only recently and they're basically the only ones doing that, I think), so no difference there. But both Lua and JavaScript are organized around hashtables rather than lists; maybe that's the biggest difference data structure-wise.

If an academic at a university designs a language for Petrobras it's not accurate to say it was designed by an academic?

Its true but misleading.

the devil in the details

With MoonScript you even have CoffeeScript there.

http://moonscript.org/

I really hope someone will do the same with Io. Such a lovely little language.

Reply on news.ycombinator.com