Lua and Python

Posted Feb 12, 2020 3:01 UTC (Wed) by smoogen (subscriber, #97)
In reply to: Lua and Python by dvdeug
Parent article: Lua and Python

I think you are looking at the rare use-case where lua would be used on general usage systems. Most of the current lua use-cases are in embedded systems where gigabytes are expensive in the amount of electricity you have a budget for and you may have a 64 bit cpu but only megabytes of memory. [We aren't talking something luxurious like a flip phone either.. this might be something embedded in a remote sensor or some other constrained device.]

Even when you are on a system with 'loads' of RAM (say a lightbulb or a phone), you are going to be embedded in another program where every extra bit of memory you don't use is something that program can't. This means that anything which looks like bloat is jettisoned.

The context here is important because the original author (and most of the core lua people ) is going to be worried about that scenario. Any 'blessed' library is going to be wanted to be used in those environment (just as much as people want the full python standard ones to be available in micropython or micropython is useless to them).

Lua and Python

Posted Feb 12, 2020 17:43 UTC (Wed) by admalledd (subscriber, #95347) [Link]

This exactly on the common constraints Lua is used under. We use Lua embedded in our own product which does run on 'loads of CPU and RAM', but we use Lua as a safe sandbox (through many sanity/safety layers and <redacted> cheating protection) to run basically user/client provided code when we process their work. One of the _small_ jobs entails executing something on the lines of 100,000 short Lua scripts. We are also constrained on "faster we go more $$" so of course we multithread, but now that means each and every Lua stack, variable, byte of memory used is multiplied.

So we strip even the standard lib (of course things like the `debug` module or `io` are right out for "don't trust the user" reasons!) down to as little as we can allow. A few memory pool tricks here-and-there too.

So even when embedded Lua is used on a big server (woo triple digit cores! 512GB+ ram!) we have to run _multiple_ instances of our process in parallel, and it itself is threaded, so suddenly we do start to care here too.

In the end, I am all for at least better "hey you are trying to read XML/JSON/YAML in Lua? here is are some modules or examples to look at" documentation/lists to exist. It is very rare if ever we developers need to write something new, the challenge is even finding said existing prior work to use/improve even when we want to. Would have made the initial integration less rocky.