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

http://lua-list.2524044.n2.nabble.com/ANN-Luvit-Lua-UV-Jit-NodeJS-re-implemented-in-Lua-td7048032.html

by Yakulu • 15 years ago

158 37 15 years ago

lua-list.2524044.n2.nabble.com

kristopher• 15 years ago

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.

jobliz• 15 years ago

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.

justincormack• 15 years ago

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

mhd3• 15 years ago

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/

luastoned3• 15 years ago

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.

ggr• 15 years ago

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

davnola• 15 years ago

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

mhd3• 15 years ago

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/

josephg• 15 years ago

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?

willvarfar• 15 years ago

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

slig• 15 years ago

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

obtu• 15 years ago

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

Yakulu• 15 years ago

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.

creationix3• 15 years ago

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.

luastoned3• 15 years ago

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

luastoned3• 15 years ago

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...

dextorious• 15 years ago

"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".

creationix3• 15 years ago

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.

po• 15 years ago

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...

olegp• 15 years ago

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.

diamondhead• 15 years ago

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.

VMG• 15 years ago

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.

fab13n• 15 years ago

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.

omaranto2• 15 years ago

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.

omaranto2• 15 years ago

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

perfunctory• 15 years ago

the devil in the details

substack• 15 years ago

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.

compay• 15 years ago

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

https://github.com/ignacio/LuaNode

tete• 15 years ago

With MoonScript you even have CoffeeScript there.

http://moonscript.org/

randallsquared• 15 years ago

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.

creationix3• 15 years ago

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.

radagaisus• 15 years ago

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

mambodog• 15 years ago

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/

gregholmberg2• 15 years ago

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!

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

Related Stories