alt Hacker NewsIn my opinion, Lua would kill for many use cases... If it had a bigger standard library, and batteries-included module/packaging system. I know LuaRocks exists, but it doesn't seem terribly common.
Types/type checking would also be nice. Luau does seem to offer some level of static typing, but it isn't used by a whole lot that I've seen.
That said, I think a lot of people are also glad it doesn't include much, because one of the biggest draws of Lua is that it's extremely compact and embeddable. And I do understand that, too. I remain a huge fan of Love2d even though I haven't actually released anything with it.
Replies
> In my opinion, Lua would kill for many use cases
Perhaps it could, but it should?
Let me explain. Take the example of JavaScript, which was kinda similar to Lua when it was conceived: both were simple languages, targeted to solve specific problems, waiving more complex features and delegating many things to their users.
Example: early JS and Lua don't have OO, but they have the tables (Lua) and objects (JS) which are hash tables with some syntax sugar to look like POO languages if you needed. Then, the user is responsible to handle this in a sane way, which should not be big deal for the scenario that those languages were created.
JS, however, has grown outside its original purpose. Somehow it became a server language, and somehow it became a monster. TypeScript, CoffeeScript, ClojureScript and others were created to delegate back stuff to the language. Lua, however, is still doing well its job in its simplicity.
In my use cases, I’ve appreciated how easy it is to cut out most of Lua’s standard library and run only the bare language.
As a game engine guy, I’ve been setting up Lua to be used by semi-technical game designers. I know I’m going to have to help them debug some crazy script months from now, so I want to carefully prescribe the APIs they get to play with from the beginning. Ex: No raw file system access! Only load assets through the asset system.
Lua shines when it is embedded in a larger program, giving high-level commands. There have been plenty of projects trying to build full applications in Lua. But, that’s really fighting against its design.
> In my opinion, Lua would kill for many use cases... If it had a bigger standard library, and batteries-included module/packaging system. I know LuaRocks exists, but it doesn't seem terribly common.
This is because of the design choice of Lua. Authors do not ensure retro compatibility and this is why there were so much outdated external libraries when Lua 5.2 came in. Even the most popular LuaSocket wasn't updated in years.
In fact, Lua is definitely not intended to be used as a drop-in replacement to Python, Ruby or Perl because of that. It's entirely designed to be embedded as-in in your host-program and that you must provide your own extensions.
However, keep in mind that:
a. you will need to carry the documentation of Lua you've included b. if you plan to upgrade the bundled Lua you will have to polyfill all changes to avoid breaking your userbase code (and this is a real PITA) c. you'll end up with lots of `#ifdef` in your code
I think that are few reasons why Lua stalled that much (without even mentioning all uncommon features `~=`, `goto`/`break` but no `continue`, array start at 1, too minimalist unicode support, ...). I've been including Lua 5.1, 5.2 and 5.3 in one of my projects before I eventually stopped to backport compatibility layers. I also gave up on my LuaSDL repository because it was too much of headaches. It's a shame because I loved this language a lot.