You raise some good points; I understand you're playing the devil's advocate but I thought a few would benefit from a friendly counter :)
> ... everyone stumbles across is the "counting from 1" ...
Fair enough :) I find this objection to be largely a matter of taste; it was never an issue for me [added in edit: even when interoperating with C and JS code]. People have made similar complaints about Matlab that I never found persuasive (there are other more persuasive criticisms of Matlab's language design). I think the core argument I'd make here is that if you're using Lua tables in a way that requires array-offset semantics for the index variable, you could probably step up a level of abstraction using ipairs/pairs and save yourself worrying about 1 vs 0.
> The impedance-mismatch becomes even more apparent when the table-abstraction meets serialization.
Lua tables naturally serialize to Lua table syntax (modulo cycles). This is in fact Lua's origin story (if Lua were a spiderman comic, it would be a story of a table description language being bitten by a radioactive register-based VM). At a technical level, how are Lua table literals any less successful a serialization format than JSON (i.e. JS object literals)? To put it another way: JSON doesn't map naturally to XML; should we then conclude that it has an impedance mismatch with respect to serialization?
> doesn't have an established package manager ...
<old guy hat>
The idea that a language should have a package manager has always seemed... confusing... to me. C doesn't have a package manager; people still seem to be able to get the relevant packages when they need them through the OS's package manager. That, to me, seems the sane solution. I realize I may be in the minority.
</old guy hat>
Having said that I agree that LuaRocks' comparative weakness relative to Ruby's gems limits adoption in mainstream programming applications. OTOH, it is vastly easier to get started embedding Lua in a host program than any of its competitors (this is in fact what drove me to try it in the first place). So it's not all friction on the deployment story.
> ... many of the driving people behind Lua just don't care about it becoming a mainstream language or not.
Yes, I think this is likely true. I don't think any of the core contributors care about it being "the next Python/Ruby/Perl". If I had to summarize the emergent aesthetic, it's that Lua is designed to be a just a language with a large set of DIY practices around it, rather than a curated software ecosystem.
> C doesn't have a package manager; people still seem to be able to get the relevant packages when they need them through the OS's package manager.
This is fine with Linux, which has at least a few sane package management systems between the different distros. This goes out the window with OS X and Windows.
(This may just be an argument that anyone working on server-side software should be working inside a VM that matches your production environment. The Ruby community seems to have shown that people push back very hard on that.)
In the particular case of Nginx and Lua, the OpenResty package[1] is pretty much self contained except for libpcre.
Nginx+Lua is only the core part that powers this ecosystem. OpenResty comes with a lot of libraries for "usual web stuff", except maybe a default template system.
I've been using this rather simple one [2]
In the full example[3], I installed it on Mac OS
(and actually found a small problem with homebrew that should be fixed soon)
The idea that a language should have a package manager has always seemed... confusing... to me.
Yes, it's seems less than ideal, but in practice it has proven to be a significant advantage (not only) in cross-platform deployments.
The C toolchain has the benefits of being a compiled language (dynamic linking) and ubiquity (autoconf is a mess but sort of works pretty much everywhere). No other language has that, you can not even rely on a recent version of your runtime being available on a given platform. And things get really hairy when you need multiple different versions on the same host.
The rubygems+rbenv approach just works really well, almost independently of the platform that you're dealing with. And once you become used to deployment being this easy your tolerance versus languages lacking this convenience declines rapidly.
> ... everyone stumbles across is the "counting from 1" ...
Fair enough :) I find this objection to be largely a matter of taste; it was never an issue for me [added in edit: even when interoperating with C and JS code]. People have made similar complaints about Matlab that I never found persuasive (there are other more persuasive criticisms of Matlab's language design). I think the core argument I'd make here is that if you're using Lua tables in a way that requires array-offset semantics for the index variable, you could probably step up a level of abstraction using ipairs/pairs and save yourself worrying about 1 vs 0.
> The impedance-mismatch becomes even more apparent when the table-abstraction meets serialization.
Lua tables naturally serialize to Lua table syntax (modulo cycles). This is in fact Lua's origin story (if Lua were a spiderman comic, it would be a story of a table description language being bitten by a radioactive register-based VM). At a technical level, how are Lua table literals any less successful a serialization format than JSON (i.e. JS object literals)? To put it another way: JSON doesn't map naturally to XML; should we then conclude that it has an impedance mismatch with respect to serialization?
> doesn't have an established package manager ...
<old guy hat> The idea that a language should have a package manager has always seemed... confusing... to me. C doesn't have a package manager; people still seem to be able to get the relevant packages when they need them through the OS's package manager. That, to me, seems the sane solution. I realize I may be in the minority. </old guy hat>
Having said that I agree that LuaRocks' comparative weakness relative to Ruby's gems limits adoption in mainstream programming applications. OTOH, it is vastly easier to get started embedding Lua in a host program than any of its competitors (this is in fact what drove me to try it in the first place). So it's not all friction on the deployment story.
> ... many of the driving people behind Lua just don't care about it becoming a mainstream language or not.
Yes, I think this is likely true. I don't think any of the core contributors care about it being "the next Python/Ruby/Perl". If I had to summarize the emergent aesthetic, it's that Lua is designed to be a just a language with a large set of DIY practices around it, rather than a curated software ecosystem.