
Luvit – Asynchronous I/O for Lua - harrydoukas
http://luvit.io
======
zacharyvoase
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).

~~~
leafo
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...](http://wiki.nginx.org/HttpLuaModule#ngx.location.capture_multi))
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.

------
philips
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
Keep up the good work philips! Thanks for the links!

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

~~~
bch
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>

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

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

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

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

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

~~~
buster
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

~~~
philips
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. :)

~~~
ksec
Comparatively how much memory was Node.js using?

~~~
philips
28MB - 35MB depending on the GC cycle IIRC.

------
0x1997
<https://github.com/richardhundt/luv> <https://github.com/connectFree/lev>

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

------
Mahn
"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
Yes, LuaJIT is faster than V8.

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

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

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

~~~
telemachos
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...](http://bostinno.com/2011/01/31/node-js-
interview-4-questions-with-creator-ryan-dahl/)

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

~~~
zacharyvoase
<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>

------
kernelp4nic
And luanode? <https://github.com/ignacio/LuaNode>

------
rustc
Very interesting project.

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

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

