[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] luaproc 1.0-4
- From: Phil Leblanc <philanc@...>
- Date: Tue, 6 Oct 2015 12:18:42 -0400
On Mon, Oct 5, 2015 at 9:57 AM, Hisham <email@example.com> wrote:
> Hi! Congratulations on the release!
> In any case, as I told you in our last conversation in person, I think
> a complete solution for concurrent programming necessarily involves
> something like processes/channels (luaproc) + serialization, and from
> what I gather, the lack of direction on how to take on the second half
> of the problem leads people to fragmented, homegrown solutions
> what I would like to see, as a user (and which I think is the
> best option, in fact), would be for luaproc to pick one existing
> serialization library and specify it as a default dependency.
I think one of the big strengths of the Lua Approach is to provide
mechanisms, not solutions (eg. metatables, not classes)
In the same vein, I think that Luaproc may be the best
"sane-threading" mechanism we have for the moment. And I would love to
see it --if not included in standard Lua-- at least having the same
sort of support / endorsement as LFS or LPeg.
For serialization, we have very low level mechanisms, enhanced by the
recent string.pack/unpack functions. (and maybe these two functions
could be further enhanced a bit while keeping minimalist)
It would be great to have a complete solution a la LuaLanes built on
Luaproc, but I think Luaproc should remain an independant, stand-alone
low-level mechanism. I see it a bit like Xavante vs. socket.core.