lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Tim,

I love that you're reconciling your projects with the vanilla Lua ecosystem. To be honest I had looked into Luvit roughly a year ago and was simultaneously impressed and put off by the fact that it was a separate ecosystem and didn't "improve" upon Node.js. I always thought a Lua rendition of Node.js exploiting coroutines and other Lua features could make Node.js look feeble by comparison. I'm happy that you're addressing both issues :-)

I think I see the reasons why you couldn't use luarocks and had to create lit. In my idealistic opinion, however, I think both ecosystems (Luvit and LuaRocks) would be better off by joining forces in the future. It would be awesome if Lua had only one package manager, and you could install Luvit/weblit from it.

If you feel the same, I would love to hear what you think would be necessary for a merger. A new package manager?

Personally I'd be in favor of a new decentralized package manager based on just Lua and libuv. If possible with legacy support for LuaRocks packages. Could it be LuaRocks 3.0? Lit 2.0?

Cheers

On Tue, Feb 16, 2016 at 7:21 PM Tim Caswell <tim@creationix.com> wrote:
I just wanted to chime in here as the creator of Luvit.

First I think Lift is a great project.  I'm glad my luv bindings are helping others.

Secondly, the comparison is accurate for luvit proper, but there is much more to the luvit ecosystem than just the luvit metapackage.

The luvit package aims to be a complete node.js port in lua.  This is why it's callbback based and has very similar APIs.

That said, I'm not a fan of callbacks in lua. I think it's a shame to have native coroutines in a language and not use them.

For the last year or so, I've been writing apps and libraries using luv, but with coroutines for servers and clients.  The lit package manager itself it implemented at a luvi app (not luvit) and doesn't use luvit's standard library.  It has it's own coro-* libraries that are much easier to use.  I've also written an HTTP web framework on top of these coro-* conventions at https://github.com/creationix/weblit

I'm sorry that I haven't documented this new development as well as I should for newcomers to find it.

If you want to do task automation, Lift looks great. If you want to write TCP servers, use the coro-* libraries published to lit. https://luvit.io/lit.html#coro

Also I've recently been working on an effort to make luvit's ecosystem more widely available to non-luvit developers.  Most all the popular libraries are now in a format that can be used by lua directly without luvit's custom require loader.  I've even written a custom lua loader that implements a lit compatible path resolution algorithm, but uses lua's native require (and so mixes freely with luarocks packages).

If anyone is interested, I can write up a blog post on using these libraries from vanilla lua.

-Tim Caswell

On Sun, Feb 14, 2016 at 7:12 AM, Thiago Bastos <tbastos@tbastos.com> wrote:

On Sat, Feb 13, 2016 at 3:53 PM Nagaev Boris <bnagaev@gmail.com> wrote:
On Sat, Feb 13, 2016 at 5:15 PM, Thiago Bastos <tbastos@tbastos.com> wrote:
> Good question!
>
> I think the three major points for comparison are the following:
>
> 1) Luvit is a runtime for (mostly) server-side applications, while Lift
> focus on being a framework for client-side tools, mostly development tools
> (I'm using it to write a dev tool for C++). In this respect, Lift is more
> similar to Gulp/Grunt/Jake/NPM than to Node.

Can Lift be used to create TCP server?

Technically you could create a TCP server using only luv. That would be fairly low level though, and I'm not sure which abstractions included in Luvit/Node you'd be missing (depends on your application I guess).
 
There are applications which are both servers and clients: proxies,
torrent clients, caching DNS resolvers. Can I implement them in Lift?

> 2) Luvit adopts Node's Continuation Passing Style (callbacks), which is
> conducive to "callback hell" and in my opinion more difficult to reason
> about. Lift implements a Direct Style in which concurrency is achieved with
> coroutines and without callbacks (which in my opinion leads to much simpler
> code).

>From https://luvit.io/ :
> If you don’t like callbacks and event emitters, use coroutines and write blocking style code without actually blocking your event loop!

Yes, but that's a very theoretical statement. In practice you need to create lots of abstractions, a scheduler, etc. In Lift all the work has already been done, and it took me a lot of work. All blocking calls in Lift use coroutines behind the curtains and you don't even need to know what a coroutine is.
 
> 3) While Lift fits into the standard LuaRocks ecosystem, Luvit decided to
> create its own ecosystem, with its own package manager and tools.

I think, it is a strong point of Lift.

> I'd say the only thing Luvit and Lift really have in common is that both
> projects use the "luv" library (the libuv bindings created for luvit, to
> which I'm also a contributor).
>
> Cheers!
>
> On Sat, Feb 13, 2016 at 1:45 PM Nagaev Boris <bnagaev@gmail.com> wrote:
>>
>> On Sat, Feb 13, 2016 at 3:33 PM, Thiago Bastos <tbastos@tbastos.com>
>> wrote:
>> > Dear list,
>> >
>> > I'd like to announce the first (v0.1) release of Lift, a general-purpose
>> > task automation tool for Lua with support for multitasking, streams and
>> > asynchronous I/O powered by libuv. It's available on luarocks and works
>> > on
>> > Linux, OSX and Windows.
>> >
>> > Lift was inspired by projects such as Rake, Gulp and npm, but follows a
>> > unique Lua-ish design. Check out the full list of features at:
>> >
>> > https://github.com/tbastos/lift
>> >
>> > I'm currently looking for early adopters or even contributors to help
>> > guide
>> > the development. Would you rather use Lua to automate your development
>> > workflow? Do you think Lua is currently missing a more powerful build
>> > tool/task runner/other development tool? Please check out the project
>> > and
>> > give your feedback, say which features are important and so forth.
>> >
>> > Cheers!
>>
>> Hi!
>>
>> Thank you for Lift!
>>
>> What is the relationship between Lift and Luvit [1]. Can you compare
>> them, please?
>>
>> [1] https://luvit.io/
>>
>> --
>>
>>
>> Best regards,
>> Boris Nagaev
>>
>



--


Best regards,
Boris Nagaev