I'd vote for coroutine based programming. The closure based async programing in node.js is driving me nuts. Perfectly simple goals becomes stretched and teared like warm chewing gum when jumping through just a few asnyc hoops.
Am Dienstag, 21. Oktober 2014 21:30:54 UTC+2 schrieb Tim Caswell: > > Since working on luvit became my full-time job, I've been super busy > paying off technical debt and cleaning up the lower layers and now it's > time for the interesting high-level discussions. > > So first to recap the current status. I've finished rewriting my > libuv-lua bindings. The code can be found at https://github.com/luvit/luv. > This has much better test coverage than the previous version and more > closely follows libuv. Also it uses the new libuv 1.x APis and is > currently built against libuv 1.0.0-rc3. > > Next there is a small project known as "luvi > <https://github.com/luvit/luvi>". This builds a luajit binary with the > luv bindings baked in. Also it has a tiny bootstrapper that allows LÖVE > style packaging. Simple write your app as a folder of lua files with main > being at "main.lua". Then zip this folder and append it to the luvi binary > and you now have a self-contained binary for your app without ever needing > to build luajit or luv yourself. (I'll publish binaries for all popular > platforms. Windows version can currently be found on appveyor > <https://ci.appveyor.com/project/creationix/luvi/build/artifacts>. > > The next step is to decide how to integrate this new base into luvit > itself. I have a few questions for the community. > > 1. Are you set on the node.js clone APIs currently in luvit? > > 2. Which sugar APIs from luvit do you depend on? (event emitters, objects, > streams, net, etc) > > 3. Would you like freedom to try other async styles (coroutines, channels, > etc)? > > 4. How important is the ability to ship a single binary for your project? > > 5. Would you rather use luv as a module to vanilla lua or luajit (perhaps > through luarocks)? > > I'm not in love with many of the node.js APIs even though I was there when > they were originally designed back in 2009. In particular I think the > stream interface in node is pretty bad and complex. Luvit currently > doesn't take advantage of coroutines in lua which could dramatically > simplify async work. > > I propose we break out the node.js style API sugar into a standalone > library that could be imported to a project for folks who prefer this > style. This would leave room for other styles and expose the raw > underpinnings in luvi for people like me who like working closer to the > metal. > > I'm also considering a package management system for sharing and reusing > such modules. I want to make it trivial for a community to start growing > around this tiny core and see what's important to various people. > > I've talked some to the virgo agent <http://virgoagent.com/> team at > Rackspace (of which I'm a member). I'd love to hear from someone on the > Torch7 <http://torch.ch/> team and anyone else who uses or wants to use > luv or luvit. > > Let me know what you think. > > -Tim Caswell > @creationix > > -- 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.
