Re: [ANN] Lift 0.1 looking for early adopters

[Hisham <h@...>]

On 16 February 2016 at 19:35, Thiago Bastos <tbastos@tbastos.com> wrote:
> 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?

Hi! Chiming in just to say I'm listening and enjoying this
conversation and open for suggestions for improvement and
collaboration. I'd love to hear which features are perceived as
lacking in LuaRocks in this context. For instance, what do you mean by
"decentralized package manager"? (Note that LuaRocks has support for
local repositories: --server can even point to local directories, but
you probably mean something else).

Also, there's a LuaRocks survey online that's open for receiving feedback:
http://bit.ly/luarocks

Thanks!

-- Hisham

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