Luvit – Asynchronous I/O for Lua

by harrydoukas • 14 years ago

90 36 14 years ago

philips5• 14 years ago

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/

harrydoukas• 14 years ago

Keep up the good work philips! Thanks for the links!

beck5• 14 years ago

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!

cicloid• 14 years ago

Probably you'll see even more in the coming months. With Redis support and even nginx. This could be huge!

And the language looks nice!.

ksec2• 14 years ago

I am expecting some momentum too once Nginx and Redis Lua support both grow together.

arocks• 14 years ago

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.

buster2• 14 years ago

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?

pepve• 14 years ago

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.

buster2• 14 years ago

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

jacques_chester2• 14 years ago

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.

zacharyvoase2• 14 years ago

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

philips5• 14 years ago

Tim Caswell, who started luvit, has been exploring ideas along those lines: http://lua-users.org/lists/lua-l/2012-10/msg00181.html

dyselon• 14 years ago

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.

leafo• 14 years ago

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.

tokipin• 14 years ago

personally i was surprised node.js wasn't node.lua in the first place

andrewflnr• 14 years ago

I think part of the idea of node was to use the same language on the front end and back end.

tbranyen• 14 years ago

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.

telemachos• 14 years ago

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

njharman• 14 years ago

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.

zacharyvoase2• 14 years ago

<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

bch2• 14 years ago

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

bch2• 14 years ago

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

account_taken• 14 years ago

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.

rustc• 14 years ago

Very interesting project.

Is there any list of what all parts of node.js have been implemented till now?

philips5• 14 years ago

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.

Mahn• 14 years ago

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

justincormack• 14 years ago

Yes, LuaJIT is faster than V8.

0x1997• 14 years ago

https://github.com/richardhundt/luv https://github.com/connectFree/lev

alberth• 14 years ago

How does Luvit compare to Zed Shaw's Tir [1] framework? They both seem to have the same goal.

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

codewright• 14 years ago

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.

otterley• 14 years ago

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.

kernelp4nic• 14 years ago

And luanode? https://github.com/ignacio/LuaNode

Luvit – Asynchronous I/O for Lua

Related Stories