Hi Alek, Thiago's points were the following [paraphrasing]:
1) Lift is better for client side 2) Luvit uses callbacks 3) Lit package manager Let me start out by mentioning that Luvit exists within a stack: Luv (libuv bindings), Luvi (a common executable), Lit (Package Manger), and Luvit (a module found within Lit). In version 2 of Luvit the goal was to split a part the dependencies where a user could use Luv and Luvi without needing to use Luvit. Lit is written entirely in blocking co-routine style of code getting all the benefits of the asynchronous libuv backend. Luvit kept with backwards compatibility and preserves the nodejs/callback style but the callbacks are entirely optional. Tim wrote many coro-* style modules that fit nicely into the Luvi eco-system providing the coroutine functionality [1]. The Luvit/luvi ecosystem is used interchangeably with client side or server side code. I don't quite understand Thiago's distinction. We have a package manager for Lit and works great for projects that you want to use luvi with. It really is a nice addition to the stack. Tim has recently gotten luv to build with luarocks and it is now in their repository as well. For me, Lift looks pretty similar to Luvi+Coroutine modules. We probably have not advertised the co-routine style enough with the new 2.0 stack, but it does exist and works well. Luvit's goal will continue to be callback style; however, Luvit will not dictate the lower portions of the stack. Luvit is basically a npm module now; pluggable within user's applications and totally optional. Regards, Ryan [1] https://github.com/luvit/lit/tree/master/deps On Tue, Feb 16, 2016 at 7:30 AM, Alek Paunov <[email protected]> wrote: > Hi guys, > > Few days ago, in the Lua ML, new interesting Lua tool and module - Lift > [1] was announced, which also happened to be libuv based. Immediately > the question: > > "What is the relationship between Lift and Luvit. Can you compare > them, please?" > > was asked. The author of the tool - Thiago tried to shed some light: > > http://lua-users.org/lists/lua-l/2016-02/msg00131.html > > But as far as I correctly follow more recent directions in Luvit design > evolution, Thiago describes earlier versions of the Luvit vision. > > I am forwarding this to Luvit ML, because since then no one > stepped to clarify the actual Luvit state in this thread, and I > unfortunately do not have enough Luvit knowledge (and English) to post a > decent update. > > Kind Regards, > Alek > > [1] https://github.com/tbastos/lift > > -- > You received this message because you are subscribed to the Google Groups > "luvit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "luvit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
