6 ms·

I think a lot of people complain about Lua because they are trying use use it as a Python alternative. Lua and Python are suited for very, very different tasks

I think a lot of people complain about Lua because they are trying use use it as a Python alternative. Lua and Python are suited for very, very different tasks. If you are whipping up a command-line script because what you want is too complex to attempt in Bash, use Python. Lua is terrible for this. If you are making an application from scratch using just the stand-alone interpreter, your scripts and a bunch of dependencies from the internets, use Python. People work really hard to make this semi-viable in Lua, but it is a path of frustration. If you have your own C/C++ program and you want an easy path for configuring and composing features that are written in C/C++, deciding between Lua and Python depends on your goals. Do you want MAXIMUM POWER for the scripter to whip together any crazy feature they might dream of? No concerns about footguns, hanging ropes or corner-painting? Memory and performance are secondary concerns to flexibility? Go use Python! Do you want minimum power for the scripter so as to keep their creations constrained within a defined box? Is there a pre-defined role that the script will play? Are there definite restrictions on what should and should not be done in scripts? Are you going to be responsible in practice for debugging some monstrosities that the scripters build for themselves? Are performance and memory primary concerns above flexibility? Then Lua is well suited for embedding into your application.

greenshackle2 6y ago
Yes, this. We use Lua for embedding and even the few batteries were more than we wanted. We stripped out file and network I/O and some other stuff I can't remember right now.
- einpoklum 6y ago
  "Batteries included" doesn't mean you have to _use_ the included batteries... or like Lorenzo Donati says in the article: > "But no one is suggesting that a set of batteries become a requirement for Lua—even the existing Lua standard library can be compiled out for use cases where it is not needed"
  - greenshackle2 6y ago
    Sure, yeah, you can try to make future Lua do both what current Python and current Lua do well. I, personally, don't see the appeal, because Python already exists - the only reason I use Lua is that it fills a niche that Python doesn't. It's great at filling that niche but if I want something like Python I just use Python.
outworlder 6y ago
Also do you want a really tiny interpreter, with little in the way of dependencies, with outstanding and easy to use FFI? Use Lua.
vvanders 6y ago
I'll add one other point which is that in memory constrained platforms Lua is unrivaled in its ratio of power/memory footprint. Back in games we put the whole game state (including ai routines written by designers using coroutines) in a 400kb preallocated block on a system that had only 8mb of system ram. Worked like a champ.
- corysama 6y ago
  The classic Doug Lea's Malloc with #define ONLY_MSPACES is great for this. That way you can constrain not only Lua's memory usage, but also it's fragmentation. We'd also manually run a fixed number of GC steps per frame in our games. The higher average CPU use was worth the much lower variance.
Jason_Gibson 6y ago
And to expand on this, it's easier to add features to a language than to remove them. If one's design requires certain runtime constraints (ability to hook into interpreter execution and memory allocation, no per-process global restrictions), packaging (e.g. static linking), and ease of portability, then starting off on the minimal side (Lua) is better than trying to strip things off of a larger (Python) runtime. You can also get to a middle-ground state between "no batteries" and "just enough batteries" to get a large portion of the expected work done if the problem space is understood and has some bounds. E.g. including a library to make HTTP requests, parse JSON and work with an embedded SQL database will be enough for a lot of use-cases in the "user-defined glue logic on an existing application" space.
vlovich123 6y ago
Serious question since you have familiarity here. Why not something like Wasmr instead to provide the runtime hooks into your code and letting the user pick whichever language they want?
- corysama 6y ago
  I have not dug into WASM myself. But, I've heard there are multiple implementations out there that are very nicely embeddable. They might well be good competition for Lua. I guess I'd ask a few different questions. Who is your target audience? Are they professional coders or semi-technical users? Are they in-house or are the customers in the wild? If you have in-house coders who can't agree on what language to use, I guess WASM could allow them to agree to disagree. I'm not sure if that's a better path than using the languages' native tools and focusing on improving the compile-debug iteration time. If you have external coder customers who will demand differing languages, WASM sounds great! If you have external, semi-technical users who don't flat-out demand JavaScript-or-Die, standardizing on either Lua or Python is probably better for them both in terms of complexity and consistency of documentation and community help. In general, for semi-technical users, see my above post on power levels.
pjmlp 6y ago
> If you have your own C/C++ program and you want an easy path for configuring and composing features that are written in C/C++, deciding between Lua and Python depends on your goals. I would rather use Tcl for that purpose :)
pansa2 6y ago
> If you are making an application from scratch using just the stand-alone interpreter, your scripts and a bunch of dependencies from the internets, use Python. People work really hard to make this semi-viable in Lua, but it is a path of frustration. It's unfortunate that Lua doesn't work well for this. The Lua implementation's light weight, portability and robustness [0] seem ideal for building these applications - especially for building applications that can be distributed to end-users (a scenario which is not a focus of Python [1]). Obviously Lua is never going to include a large standard library because that conflicts with its embeddability. However, even in the Python community, “batteries included” is no longer considered entirely beneficial [2]. Instead, I think Lua would benefit from a set of officially recommended external libraries. This would improve the situation for people trying to write standalone applications in Lua, and I believe it would also help those who are writing scripts targeting embedded interpreters. [0] https://www.lua.org/bugs.html https://www.lua.org/bugs.html [1] https://twitter.com/gvanrossum/status/1347045076401147904 https://twitter.com/gvanrossum/status/1347045076401147904 [2] https://lwn.net/Articles/790677/ https://lwn.net/Articles/790677/
- pull_my_finger 6y ago
  Having a set of "blessed" libraries has definitely been discussed on the mailing list. Also there are plenty of "distributions" like Lua for Windows[1], LuaPower[2], or runtimes like Luvit[3] that add features ootb. That said - the Lua ecosystem in 2021 is not the same as it was in 2005 or whenever people compare it to. There is a healthy amount of Libraries and choices of libraries for solving most tasks on Luarocks. And I would suggest you produce a better end project by selecting which libraries are included in your project that uses Lua for scripting. You can even further remove your choice of the libraries that _are_ included ootb. [1] - https://github.com/rjpcomputing/luaforwindows https://github.com/rjpcomputing/luaforwindows [2] - https://luapower.com/ https://luapower.com/ [3] - http://luvit.io/ http://luvit.io/

greenshackle2 6y ago

Yes, this. We use Lua for embedding and even the few batteries were more than we wanted. We stripped out file and network I/O and some other stuff I can't remember right now.

einpoklum 6y ago
"Batteries included" doesn't mean you have to _use_ the included batteries... or like Lorenzo Donati says in the article: > "But no one is suggesting that a set of batteries become a requirement for Lua—even the existing Lua standard library can be compiled out for use cases where it is not needed"
- greenshackle2 6y ago
  Sure, yeah, you can try to make future Lua do both what current Python and current Lua do well. I, personally, don't see the appeal, because Python already exists - the only reason I use Lua is that it fills a niche that Python doesn't. It's great at filling that niche but if I want something like Python I just use Python.

outworlder 6y ago

Also do you want a really tiny interpreter, with little in the way of dependencies, with outstanding and easy to use FFI? Use Lua.

vvanders 6y ago

I'll add one other point which is that in memory constrained platforms Lua is unrivaled in its ratio of power/memory footprint. Back in games we put the whole game state (including ai routines written by designers using coroutines) in a 400kb preallocated block on a system that had only 8mb of system ram. Worked like a champ.

corysama 6y ago
The classic Doug Lea's Malloc with #define ONLY_MSPACES is great for this. That way you can constrain not only Lua's memory usage, but also it's fragmentation. We'd also manually run a fixed number of GC steps per frame in our games. The higher average CPU use was worth the much lower variance.

Jason_Gibson 6y ago

And to expand on this, it's easier to add features to a language than to remove them. If one's design requires certain runtime constraints (ability to hook into interpreter execution and memory allocation, no per-process global restrictions), packaging (e.g. static linking), and ease of portability, then starting off on the minimal side (Lua) is better than trying to strip things off of a larger (Python) runtime. You can also get to a middle-ground state between "no batteries" and "just enough batteries" to get a large portion of the expected work done if the problem space is understood and has some bounds. E.g. including a library to make HTTP requests, parse JSON and work with an embedded SQL database will be enough for a lot of use-cases in the "user-defined glue logic on an existing application" space.

vlovich123 6y ago

Serious question since you have familiarity here. Why not something like Wasmr instead to provide the runtime hooks into your code and letting the user pick whichever language they want?

corysama 6y ago
I have not dug into WASM myself. But, I've heard there are multiple implementations out there that are very nicely embeddable. They might well be good competition for Lua. I guess I'd ask a few different questions. Who is your target audience? Are they professional coders or semi-technical users? Are they in-house or are the customers in the wild? If you have in-house coders who can't agree on what language to use, I guess WASM could allow them to agree to disagree. I'm not sure if that's a better path than using the languages' native tools and focusing on improving the compile-debug iteration time. If you have external coder customers who will demand differing languages, WASM sounds great! If you have external, semi-technical users who don't flat-out demand JavaScript-or-Die, standardizing on either Lua or Python is probably better for them both in terms of complexity and consistency of documentation and community help. In general, for semi-technical users, see my above post on power levels.

pjmlp 6y ago

> If you have your own C/C++ program and you want an easy path for configuring and composing features that are written in C/C++, deciding between Lua and Python depends on your goals. I would rather use Tcl for that purpose :)

pansa2 6y ago

> If you are making an application from scratch using just the stand-alone interpreter, your scripts and a bunch of dependencies from the internets, use Python. People work really hard to make this semi-viable in Lua, but it is a path of frustration. It's unfortunate that Lua doesn't work well for this. The Lua implementation's light weight, portability and robustness [0] seem ideal for building these applications - especially for building applications that can be distributed to end-users (a scenario which is not a focus of Python [1]). Obviously Lua is never going to include a large standard library because that conflicts with its embeddability. However, even in the Python community, “batteries included” is no longer considered entirely beneficial [2]. Instead, I think Lua would benefit from a set of officially recommended external libraries. This would improve the situation for people trying to write standalone applications in Lua, and I believe it would also help those who are writing scripts targeting embedded interpreters. [0] https://www.lua.org/bugs.html https://www.lua.org/bugs.html [1] https://twitter.com/gvanrossum/status/1347045076401147904 https://twitter.com/gvanrossum/status/1347045076401147904 [2] https://lwn.net/Articles/790677/ https://lwn.net/Articles/790677/

pull_my_finger 6y ago
Having a set of "blessed" libraries has definitely been discussed on the mailing list. Also there are plenty of "distributions" like Lua for Windows[1], LuaPower[2], or runtimes like Luvit[3] that add features ootb. That said - the Lua ecosystem in 2021 is not the same as it was in 2005 or whenever people compare it to. There is a healthy amount of Libraries and choices of libraries for solving most tasks on Luarocks. And I would suggest you produce a better end project by selecting which libraries are included in your project that uses Lua for scripting. You can even further remove your choice of the libraries that _are_ included ootb. [1] - https://github.com/rjpcomputing/luaforwindows https://github.com/rjpcomputing/luaforwindows [2] - https://luapower.com/ https://luapower.com/ [3] - http://luvit.io/ http://luvit.io/