15 ms·

Lua is a very nice piece of technology. Its source code is pretty easy to get into, the documentation is complete. It has its quirks yes, but if I need to add

by linkdd 5y ago

Lua is a very nice piece of technology. Its source code is pretty easy to get into, the documentation is complete. It has its quirks yes, but if I need to add scripting to a software, I'd consider Lua before considering writing a DSL, simply because you can pretty much embed Lua's source in your C/C++ software as a static library[0]. The stack-based approach makes it so easy to interact with C/C++, and I've been looking at the Rust bindings[1] recently out of curiosity, looks promising. [0] - https://github.com/lubgr/lua-cmake [1] - https://github.com/amethyst/rlua/blob/master/examples/guided_tour.rs

VWWHFSfQ 5y ago
I believe mlua [0] is the recommended Lua Rust binding now. [0] https://github.com/khvzak/mlua https://github.com/khvzak/mlua
- linkdd 5y ago
  Thanks, I'll take a look
cies 5y ago
If you need a few line here an there scripting, sure Lua, JS, PHP... whatever works. Using these languages for large projects is where the trouble starts: as they push you towards bad solutions that we know are bad for many decades. You need clear description of how to avoid these pittfals, or your growing codebase slowly becomes unmanageable. I ended up ditching a growing Lua codebase for this reason. Get out before it gets to big to get out.
- zerocount 5y ago
  I'm not convinced scripting languages are not suitable for large projects. It's said a lot, but I've never seen proof one way or the other. I suspect unmanageable code-bases derive from uncontrollable project forces, ignorance, or not caring, but not because of the perceived short comings of a scripting language.
  - DoctorDabadedoo 5y ago
    It's a trade off, I think. A compiled static language forces you to behave a certain way at the expense of flexibility/expressiveness, script languages are more flexible, but in a way that is easier to acquire technical debt that might be harder to move away from (IMO).
    - agumonkey 5y ago
      I'm sure with time, the dynlang prototype phase -> static in production will be the norm. Gradual typing has been improving (might not be the only way but still)
      - dbrueck 5y ago
        Yes, the problem with strong static typing in many languages is that you have to make decisions about typing at exactly the worst time (at the beginning), while you almost never know up front exactly what you need. For me the ideal would be a language with the expressiveness and fast dev times of Python, and then type information would be collected from actually running the program during development and would gradually shift from auto-generated type hints to more concrete type declarations that could be enforced but that would also assist in compilation & optimization.
        agumonkey 5y ago
        I've read people saying they do that in 70s 80s 90s.. it's probably an unavoidable phenomenon of solution space exploration. Even car makers use gradually more precise models before selling something. The type gathering from use would be nice.
        cies 5y ago
        I find that, with a good IDE, the expressiveness of some typed langs matches that of dyn typed langs. You write a bit more code (the types) when using a typed lang, but you write a bit less tests (the stand-in for types dyn langs offer) and your IDE takes care of many of your type signatures. The fast dev times, as in quick "edit -> run -> try" loops, it what I find most attractive of the dyn langs nowadays. And gradual typing might be a way to get there, although I think it is not needed (some strong typed langs have decent hot code reload).
- pull_my_finger 5y ago
  I hear this opinion a lot. What exactly is the characteristic(s) that is missing from a scripting language? IDE integration? The compile-time checking before running? Seems like these problems largely have solutions these days. With stuff like JSdoc annotations or TypeScript, or Teal in Lua land, language servers for most languages etc, unit testing. They might be solved _better_ in a lot of compiled languages, but it's not like it's the Wild West if you're using a scripting language, and you could argue the more modern design in some of them are a fair trade-off for the native compile checking.
  - deleted 5y ago
    [deleted]
  - _0w8t 5y ago
    With Typescript you need to add an extra compilation step. With that one can just as well not to embed JavaScript but write in the original language. Teal has an advantage that the typed language can be translated into Lua at runtime so during development it allows for quick prototyping and adding types when the amount of types becomes substantial. But its type system is less powerful than that of TypeScript.
    - amq 5y ago
      You can use ts-node to avoid the compilation step with typescript.
      - scns 5y ago
        Or Deno. But only on the back end.
  - cies 5y ago
    I do not prefer "scripting", but dynamic typing + poor language design. There are dyn typed langs with langs with nice designs. I like Ruby and IOScript. All lisp-like languages. And there are several dyn typed fit-for-embedded langs implemented in Rust that are very promising. This is very much my own opinion, I know. But reading the article's "cons of Lua" I immediately remembered my fight with that language. Personally I prefer typed languages nowadays. The stronger the better, as long as there is good IDE support.
- dbrueck 5y ago
  This opinion gets tossed around a lot, but I've found the opposite to be true, in part because all projects trend towards becoming an unholy mess as they grow large, so being able to accomplish a goal in significantly fewer lines of code has tangible benefits. If there actually is a correlation between high level languages and "trouble", it may be just because a high level language lets a less experienced developer (or team of developers) get farther than they otherwise would in some lower level language, i.e. the more cumbersome nature of a lower level language forces you to follow best practices earlier or the whole thing never gets off the ground, while the same sloppy devs + a higher level language might actually get as far as shipping something. Whether that is ultimately better is debatable, but the problem is more how the tool is being used than something inherent in the tool itself.
  - throw10920 5y ago
    > all projects trend towards becoming an unholy mess as they grow large, so being able to accomplish a goal in significantly fewer lines of code has tangible benefits This is a really good point that I didn't realize before - sure, languages like bash and Lua and Tcl might scale very poorly to large codebases, but because they're more expressive than some other languages (coughjavacough), you might be able to implement the functionality you need without needing a large codebase in the first place.
aeternum 5y ago
Since this is a Lua thread, your reference list should probably start at 1 rather than 0
- afiori 5y ago
  It is about embedding how easy it is to embed lua, so you should be able to use the host conventions
  - anothernewdude 5y ago
    Oh wow, that does make the non-standard array references rather catastrophic.
    - afiori 5y ago
      you wrap the host across the embedding boundary so that the host and lua can either use their own convention or have access to a special object that explicitely and clearly exposes the other convention. In general using array indexes as foreign keys should always be considered carefully. And if all you will be doing is iterating then the starting index doesn't really matter (unless you copy paste loop logic, which is a problem in itself)
      - afiori 5y ago
        Errata: you wrap the host across -> you wrap the array across
- BulgarianIdiot 5y ago
  Because of this I always thought lists should be iterable/traversable, but have no direct (numeric) index to their items.
  - stirfish 5y ago
    Like a stream?
lmm 5y ago
Why Lua rather than e.g. TCL or Python (both similarly easy to embed, but better-known as full-fledged languages)?
- roblabla 5y ago
  Python is all but "easy to embed" - for one thing it's huge, and it requires linking to native libraries which may conflict with your own (openssl comes to mind). It also has an unstable ABI (and even API in some cases). Lua, in contrast, is just a single, very lightweight DLL, with no external dependencies and a stable ABI.
  - raverbashing 5y ago
    Yeah, Python is "theoretically" easy to embed, that's why it uses the GIL In practice, it is hard to embed and we get the GIL disadvantages, so that is not working out so fine.
    - evgen 5y ago
      The GIL is less about python being easy to embed, than it is about embedding other libraries into python. The GIL was set up to make it easy to wrap C code and expose it to python code. A task for which it served quite well at the time and to be honest lasted longer than I would have expected.
- progre 5y ago
  It's my understanding that Lua can be more easely sandboxed, at least compared to Python.
- actuallyalys 5y ago
  My impression is that Python is not actually easy to embed (and I say this as a fan and frequent user of Python).
  - deleted 5y ago
    [deleted]
xvilka 5y ago
There's also Lua implementation (incomplete) in Rust - Luster[1]. [1] https://github.com/kyren/luster https://github.com/kyren/luster
- strenholme 5y ago
  Some other implementations of Lua: https://github.com/yuin/gopher-lua https://github.com/yuin/gopher-lua Lua in Go https://github.com/fengari-lua/fengari https://github.com/fengari-lua/fengari Lua in Javascript https://github.com/moonsharp-devs/moonsharp https://github.com/moonsharp-devs/moonsharp Lua in C#

by linkdd 5y ago

VWWHFSfQ 5y ago

I believe mlua [0] is the recommended Lua Rust binding now. [0] https://github.com/khvzak/mlua https://github.com/khvzak/mlua

linkdd 5y ago
Thanks, I'll take a look

cies 5y ago

If you need a few line here an there scripting, sure Lua, JS, PHP... whatever works. Using these languages for large projects is where the trouble starts: as they push you towards bad solutions that we know are bad for many decades. You need clear description of how to avoid these pittfals, or your growing codebase slowly becomes unmanageable. I ended up ditching a growing Lua codebase for this reason. Get out before it gets to big to get out.

zerocount 5y ago
I'm not convinced scripting languages are not suitable for large projects. It's said a lot, but I've never seen proof one way or the other. I suspect unmanageable code-bases derive from uncontrollable project forces, ignorance, or not caring, but not because of the perceived short comings of a scripting language.
- DoctorDabadedoo 5y ago
  It's a trade off, I think. A compiled static language forces you to behave a certain way at the expense of flexibility/expressiveness, script languages are more flexible, but in a way that is easier to acquire technical debt that might be harder to move away from (IMO).
  - agumonkey 5y ago
    I'm sure with time, the dynlang prototype phase -> static in production will be the norm. Gradual typing has been improving (might not be the only way but still)
    - dbrueck 5y ago
      Yes, the problem with strong static typing in many languages is that you have to make decisions about typing at exactly the worst time (at the beginning), while you almost never know up front exactly what you need. For me the ideal would be a language with the expressiveness and fast dev times of Python, and then type information would be collected from actually running the program during development and would gradually shift from auto-generated type hints to more concrete type declarations that could be enforced but that would also assist in compilation & optimization.
      - agumonkey 5y ago
        I've read people saying they do that in 70s 80s 90s.. it's probably an unavoidable phenomenon of solution space exploration. Even car makers use gradually more precise models before selling something. The type gathering from use would be nice.
      - cies 5y ago
        I find that, with a good IDE, the expressiveness of some typed langs matches that of dyn typed langs. You write a bit more code (the types) when using a typed lang, but you write a bit less tests (the stand-in for types dyn langs offer) and your IDE takes care of many of your type signatures. The fast dev times, as in quick "edit -> run -> try" loops, it what I find most attractive of the dyn langs nowadays. And gradual typing might be a way to get there, although I think it is not needed (some strong typed langs have decent hot code reload).
pull_my_finger 5y ago
I hear this opinion a lot. What exactly is the characteristic(s) that is missing from a scripting language? IDE integration? The compile-time checking before running? Seems like these problems largely have solutions these days. With stuff like JSdoc annotations or TypeScript, or Teal in Lua land, language servers for most languages etc, unit testing. They might be solved _better_ in a lot of compiled languages, but it's not like it's the Wild West if you're using a scripting language, and you could argue the more modern design in some of them are a fair trade-off for the native compile checking.
- deleted 5y ago
  [deleted]
- _0w8t 5y ago
  With Typescript you need to add an extra compilation step. With that one can just as well not to embed JavaScript but write in the original language. Teal has an advantage that the typed language can be translated into Lua at runtime so during development it allows for quick prototyping and adding types when the amount of types becomes substantial. But its type system is less powerful than that of TypeScript.
  - amq 5y ago
    You can use ts-node to avoid the compilation step with typescript.
    - scns 5y ago
      Or Deno. But only on the back end.
- cies 5y ago
  I do not prefer "scripting", but dynamic typing + poor language design. There are dyn typed langs with langs with nice designs. I like Ruby and IOScript. All lisp-like languages. And there are several dyn typed fit-for-embedded langs implemented in Rust that are very promising. This is very much my own opinion, I know. But reading the article's "cons of Lua" I immediately remembered my fight with that language. Personally I prefer typed languages nowadays. The stronger the better, as long as there is good IDE support.
dbrueck 5y ago
This opinion gets tossed around a lot, but I've found the opposite to be true, in part because all projects trend towards becoming an unholy mess as they grow large, so being able to accomplish a goal in significantly fewer lines of code has tangible benefits. If there actually is a correlation between high level languages and "trouble", it may be just because a high level language lets a less experienced developer (or team of developers) get farther than they otherwise would in some lower level language, i.e. the more cumbersome nature of a lower level language forces you to follow best practices earlier or the whole thing never gets off the ground, while the same sloppy devs + a higher level language might actually get as far as shipping something. Whether that is ultimately better is debatable, but the problem is more how the tool is being used than something inherent in the tool itself.
- throw10920 5y ago
  > all projects trend towards becoming an unholy mess as they grow large, so being able to accomplish a goal in significantly fewer lines of code has tangible benefits This is a really good point that I didn't realize before - sure, languages like bash and Lua and Tcl might scale very poorly to large codebases, but because they're more expressive than some other languages (coughjavacough), you might be able to implement the functionality you need without needing a large codebase in the first place.

aeternum 5y ago

Since this is a Lua thread, your reference list should probably start at 1 rather than 0

afiori 5y ago
It is about embedding how easy it is to embed lua, so you should be able to use the host conventions
- anothernewdude 5y ago
  Oh wow, that does make the non-standard array references rather catastrophic.
  - afiori 5y ago
    you wrap the host across the embedding boundary so that the host and lua can either use their own convention or have access to a special object that explicitely and clearly exposes the other convention. In general using array indexes as foreign keys should always be considered carefully. And if all you will be doing is iterating then the starting index doesn't really matter (unless you copy paste loop logic, which is a problem in itself)
    - afiori 5y ago
      Errata: you wrap the host across -> you wrap the array across
BulgarianIdiot 5y ago
Because of this I always thought lists should be iterable/traversable, but have no direct (numeric) index to their items.
- stirfish 5y ago
  Like a stream?

lmm 5y ago

Why Lua rather than e.g. TCL or Python (both similarly easy to embed, but better-known as full-fledged languages)?

roblabla 5y ago
Python is all but "easy to embed" - for one thing it's huge, and it requires linking to native libraries which may conflict with your own (openssl comes to mind). It also has an unstable ABI (and even API in some cases). Lua, in contrast, is just a single, very lightweight DLL, with no external dependencies and a stable ABI.
- raverbashing 5y ago
  Yeah, Python is "theoretically" easy to embed, that's why it uses the GIL In practice, it is hard to embed and we get the GIL disadvantages, so that is not working out so fine.
  - evgen 5y ago
    The GIL is less about python being easy to embed, than it is about embedding other libraries into python. The GIL was set up to make it easy to wrap C code and expose it to python code. A task for which it served quite well at the time and to be honest lasted longer than I would have expected.
progre 5y ago
It's my understanding that Lua can be more easely sandboxed, at least compared to Python.
actuallyalys 5y ago
My impression is that Python is not actually easy to embed (and I say this as a fan and frequent user of Python).
- deleted 5y ago
  [deleted]

xvilka 5y ago

There's also Lua implementation (incomplete) in Rust - Luster[1]. [1] https://github.com/kyren/luster https://github.com/kyren/luster

strenholme 5y ago
Some other implementations of Lua: https://github.com/yuin/gopher-lua https://github.com/yuin/gopher-lua Lua in Go https://github.com/fengari-lua/fengari https://github.com/fengari-lua/fengari Lua in Javascript https://github.com/moonsharp-devs/moonsharp https://github.com/moonsharp-devs/moonsharp Lua in C#