Luvit – Asynchronous I/O for Lua(luvit.io)
luvit.io
Luvit – Asynchronous I/O for Lua
http://luvit.io
15 comments
Once you have this callback-based approach at a relatively stable level, it would be interesting to then take advantage of Lua's coroutines. IMHO Lua has one of the best implementations of coroutines in recent languages, and adding libuv to that mixture could be dangerous (in a good way).
I also agree this is a very powerful approach. If you'd like to see it in action already you should check out [OpenResty](http://openresty.org/). It's a platform for doing Lua directly on top of nginx. Each request can run Lua from within a coroutine, and and you can issue nginx subrequests which block Lua code but don't block the sever. See [ngx.location.capture](http://wiki.nginx.org/HttpLuaModule#ngx.location.capture) and [ngx.location.capture_multi](http://wiki.nginx.org/HttpLuaModule#ngx.location.capture_mul...) for issuing multiple in parallel.
nginx's subrequests can do just about anything with the right modules, from database queries to HTTP requests. Effectively turning nginx into your event loop. It's a very interesting idea.
I've just started using it, but I'm excited to make something with it.
nginx's subrequests can do just about anything with the right modules, from database queries to HTTP requests. Effectively turning nginx into your event loop. It's a very interesting idea.
I've just started using it, but I'm excited to make something with it.
A while back I started to mess around with lua + libuv, and found it pretty easy to write "blocking" functions that would yield to its caller a function responsible for setting up the requisite events to wake itself back up.
If you want to see what this would look like, it's extremely ugly since I didn't work on it much (as it was easier to just use luvit and node-fibers), but I did put it up on github at http://github.com/dyselon/loquat, and you can see examples of it in the timer example of the readme, and the uncommented parts of examples/test.lua. Maybe it'll be of some use or inspiration to someone.
There a lot of cruft in those examples, but in practical usage, everything but your blocking calls would be hidden behind libraries. It's pretty easy to set up similar fiber-friendly wrappers for your favorite node.js libraries, too, if you're fond of the node-fibers add-on.
If you want to see what this would look like, it's extremely ugly since I didn't work on it much (as it was easier to just use luvit and node-fibers), but I did put it up on github at http://github.com/dyselon/loquat, and you can see examples of it in the timer example of the readme, and the uncommented parts of examples/test.lua. Maybe it'll be of some use or inspiration to someone.
There a lot of cruft in those examples, but in practical usage, everything but your blocking calls would be hidden behind libraries. It's pretty easy to set up similar fiber-friendly wrappers for your favorite node.js libraries, too, if you're fond of the node-fibers add-on.
Tim Caswell, who started luvit, has been exploring ideas along those lines: http://lua-users.org/lists/lua-l/2012-10/msg00181.html
I am one of the maintainers of luvit. There is a meetup in SF on December 6th about it if you are in the area[1].
Also, I wrote a blog post about luvit after a talk I gave at Open Source Bridge which might be helpful in providing some context[2].
[1]: http://www.meetup.com/lua-devs/events/89091842/
[2]: http://ifup.org/2012/07/03/luvit-nodes-ziggy-stardust/
Also, I wrote a blog post about luvit after a talk I gave at Open Source Bridge which might be helpful in providing some context[2].
[1]: http://www.meetup.com/lua-devs/events/89091842/
[2]: http://ifup.org/2012/07/03/luvit-nodes-ziggy-stardust/
Keep up the good work philips! Thanks for the links!
If the "node.js' awesome architecture" is referring primarily to its event-oriented/asynchronous architecture, Tcl has an incredibly robust event-oriented mechanism[1][2] for those interested in playing with it. Looking forward to seeing what shakes out in this arena. Culturally, Tcl has been heavily event-oriented[3] for a long time, so it'll be interesting to see what others chose to do with it.
[1] http://www.beedub.com/book/2nd/event.doc.html
[2] http://wiki.tcl.tk/489
[3] http://news.ycombinator.com/item?id=399670
edit: footnotes
[1] http://www.beedub.com/book/2nd/event.doc.html
[2] http://wiki.tcl.tk/489
[3] http://news.ycombinator.com/item?id=399670
edit: footnotes
Some people also suggested I remind that Tcl has coroutines[1] and a very solid threading model as well[2].
[1] http://wiki.tcl.tk/21446
[2] http://wiki.tcl.tk/1235
[1] http://wiki.tcl.tk/21446
[2] http://wiki.tcl.tk/1235
With Lua JIT being one of the fastest dynamic language implementations and having none of the 'ugly parts' of Javascript, the project sure sounds promising. Less than one-tenth of Node's memory usage makes it even better.
Lua seems to be a bit of a sleeping giant in web development so it will be interesting to see what becomes of this. Momentum is vital, this is something node.js has in spades which is resulting in a very polished and robust product, great ecosystem and wide adoption. That will be the hardest thing for luvit to replicate. Good luck!
One thing to keep in mind, this is not the Lua most people are familiar with. Yes the language is the same, but the module system is completely different to be more like Node's. I was disappointed when I first tried it but I understand the reasons.
The question here is if luvit is 2-4 times faster then node.js with "hello world" because it implements much less functionality then node.js?
This is besides the point. Judging platforms using trivial benchmarks is utterly useless.
Also, I think they shouldn't have made it the third sentence anyone reads about their project.
Also, I think they shouldn't have made it the third sentence anyone reads about their project.
Yes and i was seeing the first comment to emerge here that went "uh yeah, lua is sooo fast and lean, the software will be soo fast as well" which may just be not true at all :P
The speed claim should probably be replaced with memory numbers. We are using luvit on a project because it uses much less memory than node.js and yet allows the team to use a familiar programming model.
Right now our project weighs in at about 4.5 MB RSS with statically linked in openssl. :)
Right now our project weighs in at about 4.5 MB RSS with statically linked in openssl. :)
If you're just using OpenSSL for primitives, look at PolarSSL. I, a total newb, managed to wrap the SHA functions without too much fuss before I moved on (long story).
https://github.com/jchester/lua-polarssl
https://github.com/jchester/lua-polarssl
I suspect that in no small part the performance edge is due to Mike Pall's LuaJIT, which absolutely thumps other dynamic language implementations.
And even the reference Lua interpreter is very fast -- it's small enough to fit entirely into a CPU cache.
And even the reference Lua interpreter is very fast -- it's small enough to fit entirely into a CPU cache.
We're using Node.js as an example of something good?
Did we collectively forget everything known about concurrency once web apps got big or something?
This is embarrassing. I should switch to embedded or something.
Did we collectively forget everything known about concurrency once web apps got big or something?
This is embarrassing. I should switch to embedded or something.
Agreed - the Lua community should really focus on coroutines instead, since it actually has them, unlike Javascript. Coroutines are way easier to debug than callbacks.
"In initial benchmarking with a hello world server, this is between 2 and 4 times faster than node.js." <- Is this true? Does this mean the interpreter is faster than V8?
Yes, LuaJIT is faster than V8.
How does Luvit compare to Zed Shaw's Tir [1] framework? They both seem to have the same goal.
[1] http://tir.mongrel2.org/
[1] http://tir.mongrel2.org/
personally i was surprised node.js wasn't node.lua in the first place
Apparenly Ryan Dahl considered Lua, but he rejected it because "Lua is less ideal but a lovely language - I did not like that it already had a lot of libraries written with blocking code. No matter what I did, someone was going to load an existing blocking Lua library in and ruin it."[1]
[1] http://bostinno.com/2011/01/31/node-js-interview-4-questions...
[1] http://bostinno.com/2011/01/31/node-js-interview-4-questions...
Lua provides blocking FS methods. Node.js was designed with a language that had no notion of I/O so that the methods could all be async.
I think part of the idea of node was to use the same language on the front end and back end.
node.js has an awesome architecture?
I was hoping the "about" would, if not go into depth, at least explain wtf they thought the awesome parts are? No such luck.
I was hoping the "about" would, if not go into depth, at least explain wtf they thought the awesome parts are? No such luck.
<conjecture> the biggest unique part of node.js's architecture seems to be libuv, which is an abstraction and portability layer for event-driven I/O: https://github.com/joyent/libuv
Very interesting project.
Is there any list of what all parts of node.js have been implemented till now?
Is there any list of what all parts of node.js have been implemented till now?
You can dig through the tests to get a sense of what has been implemented. TLS, HTTP server/client, filesystem bindings, dns, etc are all working.
I have been trying to figure out what to use for docs and it seems that some markdown files and jekyll are what most recent projects have settled on: redis, yeoman.io and node.js.
I have been trying to figure out what to use for docs and it seems that some markdown files and jekyll are what most recent projects have settled on: redis, yeoman.io and node.js.