Re: Comparison of numbers of 3rd party libraries

[Andrew Starks <andrew.starks@...>]

On Tuesday, May 12, 2015, zejian ju <juzejian@gmail.com> wrote:

Yes, there's no common application platform for lua, as node.js for _javascript_.

Openresty provides a web server platform for lua based on nginx, but there's no

suitable package manager for it.

Comparing to js, I like lua because of lexical scoping, true coroutine, simple and

consistent design, and without the ugly and strange parts of js. So I hope lua can
be used pervasively.

But js seems catching up, let scoping/module/generator/async function will

appear in the coming ES6.

2015-05-13 6:46 GMT+08:00 slayer beast <slayerbeast@gmail.com>:

Also lots of Lua code is developed as scripts for applications (like
WoW addons), and those don't interact with luarocks

First, LuaRocks is very nice, and has made some excellent improvements. Also, LuaDist and ZeroBrainStudio are extremely useful. The quality of the little eccosystem that Lua does have deserves a lot of credit for the noticeable improvements that people have made. 

I'll point out that, unlike _javascript_, a defining feature of Lua is its C-API, which should be thought of as a part of the language. This means that large eccosystems will always be a side show. Very often the eccosystems belong to the application that Lua is embedded into (Wikimedia, ConTeX, Lightroom plugins). Also, developers are likely to disable many features that module writers use: coroutines, access to other modules, etc. 

The second difference is Lua's focus on embedding, especially where resources are tight. I have not heard much in the way of JS advancing the way that it is embedded into applications, outside of webbrowsers. My understanding is that decisions made early on make _javascript_ more difficult to interact with from C, than Lua, but I have not researched that. 

Lua is best compared against language libraries with similar constraints/missions, although your observations do have merit. 

-Andrew