
Show HN: LuaJIT FFI binding to libuv with coroutines - pguillory
https://github.com/pguillory/luajit-libuv
======
tiffanyh
Great work on the bindings.

Also for those of you not aware of the great work Mike Pall has done on LuaJIT
you should really look into it. He's done amazing work virtually all himself.
Please consider donating to the project to help fund and support Mike.

Mike offers all of his work under a BSD license so the community can freely,
without restriction, use his research and developments.

[http://luajit.org/sponsors.html](http://luajit.org/sponsors.html)

~~~
vbit
While I agree that LuaJIT is great piece of work, the linked page says Mike is
not accepting sponsorships at this time and there doesn't seem to be any way
to fund him.

~~~
lukego
The best way to contribute to LuaJIT seems to be to learn its internals and
make contributions, or to fund somebody else to do so. Mike encouraged this
when he gave a talk on LuaJIT in Zurich last year. His own commercial
ambitions seem to be already satisfied at the moment.

------
kodablah
In your "See Also", you missed my favorite UV+Lua combination:
[https://github.com/richardhundt/luv/tree/ray](https://github.com/richardhundt/luv/tree/ray)
(note the branch). It too uses the Lua coroutines but has a specially-built
scheduler. How does this compare to that effort, specifically, how are the
libuv event loop and the Lua coroutines combined?

~~~
justinmk
Thanks for pointing that out. I was going to ask why it appears to have
stalled a year ago, but I guess the author got distracted by something shiny:

[https://github.com/richardhundt/shine](https://github.com/richardhundt/shine)

Shine appears to address a similar need as the luv "ray" branch, _without_
libuv, with a modified version of LuaJIT[1]. I wonder if the author plans to
patch LuaJIT upstream?

A recent HN discussion[2] left me wondering where to look for a high-quality
well-maintained lua "stdlib". luvit appears to be an entire distribution with
its own package manager instead of luarocks/moonrocks. I'm now looking at luv
and luajit-libuv. shine looks like a very interesting alternative, but the
modified LuaJIT makes it problematic for deploying to users who want to use
system-provided LuaJIT.

[1]
[https://github.com/richardhundt/shine#introduction](https://github.com/richardhundt/shine#introduction)

[2]
[https://news.ycombinator.com/item?id=8191345](https://news.ycombinator.com/item?id=8191345)

~~~
srean
I might be remembering it wrong, but iirc it so transpired that there was a
thread on the Lua mailing list about the unfortunate clash in the name 'luv'.

 _richardhundt /luv_ is older of the two pieces of software but Richard
graciously offered to yield (pun intended) the name to luvit folks and
continued to develop on his code and ideas under a new name, shine.
richardhundt/luv is more than an obvious wrapper over libuv whcih is what
luvit/luv intended to be.

Please bear in mind I might have got the exact events (Gawd, pun again, this
time unintended) wrong, but if you are interested you will be able to find
this on the lua mailing list archives.

~~~
justinmk
Thanks very much.

------
curun1r
How is this different from
[https://github.com/luvit/luv](https://github.com/luvit/luv) (part of
[http://luvit.io/](http://luvit.io/))?

~~~
pguillory
In addition to what benjaminva said, luv uses callbacks (like Node.js),
whereas this uses coroutines. So for example with luv you might do something
like:

    
    
        fs.readFile(filename, function(err, data)
          -- remember to check err
        end)
    

With this binding the code would look like:

    
    
        local data = fs.readfile(filename)
        -- err was raised if one occurred
    

With coroutines, you can use exceptions and for/while loops and they continue
to work as you would expect.

------
kator
I've used openresty compiled with LuaJIT (nginx+LuaJIT) for some low latency
high scale services in the past. I wonder would this make it so I could ditch
nginx and go pure LuaJIT and still have that level of performance? Has anyone
done performance testing of this against Nginx+LuaJIT (openresty)?

~~~
davidhollander
I've implemented pure LuaJIT servers (without libuv) which compare favorably
to nginx in terms of latency and performance. But you should consider whether
or not you will need SSL\HTTPS support. libuv is only an IO loop and will not
provide this out of the box like nginx. Encryption is important and non-
trivial. Most of the projects I've seen end up back at C and embedded
Lua\LuaJIT (similar to OpenResty) rather than writing bindings and tests for
SSL in the LuaJIT FFI because of this.

~~~
luastoned
As @pygy_ said, check out [http://turbolua.org/](http://turbolua.org/)

------
otikik
In principle I prefer this to Luvit since the later uses a customized version
of LuaJIT( [https://github.com/luvit/luvit/wiki/lua-to-
luvit](https://github.com/luvit/luvit/wiki/lua-to-luvit) ) while this one uses
vanilla LuaJIT.

------
scythe
Lua's somewhat diasporic community gives it an unfortunately high barrier to
entry. It might be helpful to post this in /r/lua or on lua-l; disclosure: I
moderate the former and it's pretty small.

~~~
fit2rule
I've been a serious Lua coder for 4 years now, and I have to say that I agree
with you about the diaspora factor - Lua users aren't loud, they just get on
with using this extraordinarily powerful, small, tight tool. I feel like Lua-
heads actively resist forming big community and loud forums, because - like so
many other powerful tools - there is a covetous factor involved. ;)

But when things as elegant as luvit/lujit-libuv hit the scene, its hard not to
agree with those who have the temerity to proclaim Lua's immense usefulness to
the masses ..

Lua just plain kicks ass, its really all there is to it.

------
alco
Where is the promised "synchronous syntax"? The first example show an ordinary
async call with a callback.

------
theseoafs
What restrictions are there that keep regular Lua from being able to run this?

~~~
plorkyeran
It's built on the LuaJIT FFI, which regular Lua doesn't have. There's an
implementation of the LuaJIT FFI's API for regular Lua
([https://github.com/jmckaskill/luaffi](https://github.com/jmckaskill/luaffi)),
but the performance is underwhelming.

------
aikah
nodelua?

~~~
ludamad
There is luvit, too

------
hoelle
I work on a C/C++/Lua server stack, so this is right up my alley. But as a
MSVC native I'd have to spend hours trying to decipher your Makefile to port
it to Windows before I could even evaluate it.

~~~
seabrookmx
Out of curiosity, what do you use as your primary editor/IDE for Lua?

~~~
fit2rule
Not the OP, and not a Windows user at all (100% Linux, except for OSX
buildservers..) but I can answer as an experienced Lua developer the "IDE
Question" in two ways, for Lua scope of application, as well as developer-
style, is universal:

In a GUI scenario, I use SublimeText for all lua projects and as a cross-
platform, 'responsible editor', it provides a nice development enviroment. You
can set up buildtools, run them, get output, etc. Generally for my needs it
works fabulously. File->Open {directory of main.lua}, then everything works -
Global Definitions, Refactoring, etc. Find definitions, see global usage, etc.
Code-Completion gradually starts to work more and more, but I don't rely on
such 'features' in an IDE. I feel comfortable with little help from an IDE.

In a non-GUI scenario (embedded), I use vim+cscope as my principle IDE. Same
idea as ST - open the folder containing main.lua, work from there. Cscope
works for Lua, and is also amazing if you do FFI hacking, too .. well
generally cscope is my grep, but if I don't have it, of course grep works too
..

