4 ms·

Lua was never designed to be used for really large code basis. It's a lightweight scripting language on top of C. The entire runtime is written in 20k lines of

by kyrra 14y ago

Lua was never designed to be used for really large code basis. It's a lightweight scripting language on top of C. The entire runtime is written in 20k lines of C. It also is designed to be easily incorporated in C programs. Nginx is a popular server case, while World Of Warcraft is another popular us. It's really a pretty amazing language, when you embed it you can choose exact what functionality is exposed to the scripts you run in it, so it's pretty good for sandboxes type code (though, imposing memory restrictions is much harder).

stcredzero 14y ago
Lua was never designed to be used for really large code basis. Bases. That doesn't mean that it wouldn't be good for large code bases. Many languages end up getting used for purposes they weren't designed for.
- raylu 14y ago
  Javascript was never really designed, but look how that ended up.
_dps 14y ago
> Lua was never designed to be used for really large code basis I'd certainly agree that "maintainable for large code bases" was probably never on Ierusalimschy & Co's language design requirements document, but you could say the same of same of Perl, Python, Ruby, Javascript, and most Lisps. None of those languages have any additional mechanisms traditionally associated with enforcing uniformity and consistency across large projects. This hasn't stopped people from building large successful projects using these languages. As for your comment on the implementation size: I'm not sure which way you meant it (complimentary or pejorative) but I often find people react to this in exactly the opposite fashion I would. I see "self-ish/JS-ish/python-ish semantics in 20kloc of ANSI C? Sign me up!". I find some people see it and assume it to be a toy. It reminds me of the Bill Gates line about (paraphrasing) "measuring software's success by lines of code is like measuring an aircraft's success by its weight".
- moe 14y ago
  Playing devils advocate here, Lua does indeed have some warts that make it less pleasant to use in a heterogenous environment (which pretty much all large code-bases are). Not so much due to deficiencies in Lua but due to the impedance-mismatch versus other languages. The most obvious issue that everyone stumbles across is the "counting from 1". It seems like a minor thing, but the context-switch remains a drag when you're dealing with complex data-structures in two languages and only one of them is Lua. The impedance-mismatch becomes even more apparent when the table-abstraction meets serialization. The lack of distinction between an "array" and a "hash" is awesome when you're in a pure Lua-environment, but it becomes a real problem when you need to exchange data with languages that do depend on this distinction (e.g. if you feed Lua an empty "array" it will later serialize it back to an empty "hash"). The final issue that I can't resist mentioning here is not a language but a community/mindset one. Up to this day Lua doesn't have an established package manager akin to RubyGems, Pip, Maven, Leiningen etc. (Luarocks exists but is... well, I've yet to see someone actually using it) This is a deadly sin in terms of mainstream adoption. It makes deployment a serious pain in the ass. GoLang shows how a modern language is supposed to handle this (importing/bundling packages directly from urls). I keep hoping someone will add something similar to lua-core, but I'm sadly not very optimistic about it. I think many of the driving people behind Lua just don't care about it becoming a mainstream language or not. They care about it shining as an embedded language (and it does!) - it's just a little bitter for those of us who would love to use it on a broader scope.
  - _dps 14y ago
    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.
neopallium 14y ago
> (though, imposing memory restrictions is much harder). I developed an Emergency GC patch [1] for Lua 5.1 (Lua 5.2 come with this feature). With this feature it is easy set a per Lua State/script memory limit. The Emergency GC feature is needed to allow a custom allocator to force the GC to run when the script is at it's memory limit. My EGC patch has been in use by the eLua [2] for years to help run Lua scripts on Microcontrollers with as little as 64Kbytes of Ram. Also Lua is fine for large projects [3]. 1. http://lua-users.org/wiki/EmergencyGarbageCollector http://lua-users.org/wiki/EmergencyGarbageCollector 2. http://www.eluaproject.net/ http://www.eluaproject.net/ 3. http://prosody.im/ http://prosody.im/
tomlu 14y ago
IME Lua is neither worse nor better than (eg) Python for large code bases.
InclinedPlane 14y ago
Javascript was written by one guy in a shockingly short amount of time. What a language was intended for and what it's capable of are two very different things.

by kyrra 14y ago

stcredzero 14y ago

Lua was never designed to be used for really large code basis. Bases. That doesn't mean that it wouldn't be good for large code bases. Many languages end up getting used for purposes they weren't designed for.

raylu 14y ago
Javascript was never really designed, but look how that ended up.

_dps 14y ago

> Lua was never designed to be used for really large code basis I'd certainly agree that "maintainable for large code bases" was probably never on Ierusalimschy & Co's language design requirements document, but you could say the same of same of Perl, Python, Ruby, Javascript, and most Lisps. None of those languages have any additional mechanisms traditionally associated with enforcing uniformity and consistency across large projects. This hasn't stopped people from building large successful projects using these languages. As for your comment on the implementation size: I'm not sure which way you meant it (complimentary or pejorative) but I often find people react to this in exactly the opposite fashion I would. I see "self-ish/JS-ish/python-ish semantics in 20kloc of ANSI C? Sign me up!". I find some people see it and assume it to be a toy. It reminds me of the Bill Gates line about (paraphrasing) "measuring software's success by lines of code is like measuring an aircraft's success by its weight".

moe 14y ago
Playing devils advocate here, Lua does indeed have some warts that make it less pleasant to use in a heterogenous environment (which pretty much all large code-bases are). Not so much due to deficiencies in Lua but due to the impedance-mismatch versus other languages. The most obvious issue that everyone stumbles across is the "counting from 1". It seems like a minor thing, but the context-switch remains a drag when you're dealing with complex data-structures in two languages and only one of them is Lua. The impedance-mismatch becomes even more apparent when the table-abstraction meets serialization. The lack of distinction between an "array" and a "hash" is awesome when you're in a pure Lua-environment, but it becomes a real problem when you need to exchange data with languages that do depend on this distinction (e.g. if you feed Lua an empty "array" it will later serialize it back to an empty "hash"). The final issue that I can't resist mentioning here is not a language but a community/mindset one. Up to this day Lua doesn't have an established package manager akin to RubyGems, Pip, Maven, Leiningen etc. (Luarocks exists but is... well, I've yet to see someone actually using it) This is a deadly sin in terms of mainstream adoption. It makes deployment a serious pain in the ass. GoLang shows how a modern language is supposed to handle this (importing/bundling packages directly from urls). I keep hoping someone will add something similar to lua-core, but I'm sadly not very optimistic about it. I think many of the driving people behind Lua just don't care about it becoming a mainstream language or not. They care about it shining as an embedded language (and it does!) - it's just a little bitter for those of us who would love to use it on a broader scope.
- _dps 14y ago
  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.

neopallium 14y ago

> (though, imposing memory restrictions is much harder). I developed an Emergency GC patch [1] for Lua 5.1 (Lua 5.2 come with this feature). With this feature it is easy set a per Lua State/script memory limit. The Emergency GC feature is needed to allow a custom allocator to force the GC to run when the script is at it's memory limit. My EGC patch has been in use by the eLua [2] for years to help run Lua scripts on Microcontrollers with as little as 64Kbytes of Ram. Also Lua is fine for large projects [3]. 1. http://lua-users.org/wiki/EmergencyGarbageCollector http://lua-users.org/wiki/EmergencyGarbageCollector 2. http://www.eluaproject.net/ http://www.eluaproject.net/ 3. http://prosody.im/ http://prosody.im/

tomlu 14y ago

IME Lua is neither worse nor better than (eg) Python for large code bases.

InclinedPlane 14y ago

Javascript was written by one guy in a shockingly short amount of time. What a language was intended for and what it's capable of are two very different things.