10 ms·

I imagine this would be an alternative where embedded Lua gets used. A comparison with Lua would have been great to see. The 200K runtime, for example, indicate

I imagine this would be an alternative where embedded Lua gets used. A comparison with Lua would have been great to see. The 200K runtime, for example, indicates that this might weigh in somewhat heavier than Lua.

vorpalhex 6y ago
As someone who just worked on a project where I embedded lua, that's exactly what I was looking for. Why would I want to choose this over lua and what's the pro/con matrix?
- kevin_thibedeau 6y ago
  0-based array indexing and local scoping by default.
  - VWWHFSfQ 6y ago
    would have to do better than that
  - rumanator 6y ago
    If that's the best you can come up with then I'm afraid there isn't much of a case to use this over lua.
theptip 6y ago
Agreed, Lua seems to be the de-facto standard here, as it's so lightweight to embed. But the language has some pretty janky rough edges (e.g. only having Tables and no other data structures) so a modern alternative would be nice.
- runawaybottle 6y ago
  Isn’t that what makes it lightweight? It literally doesn’t have the extra weight.
- tastyminerals 6y ago
  Once you get to know Lua tables and then metatables, you will question the existence of different data structures :)
  - jmiskovic 6y ago
    Yes, Lua tables are incredibly versatile tool. I'm not a fan of global-scope-by-default and of verbosity, but other than that it's a fantastic language.
    - craftinator 6y ago
      I think global by default is one of the reason Lua shines in the embedded world. Not many other arenas where that is good practice.
      - zem 6y ago
        editor scripting, perhaps
      - centimeter 6y ago
        Global scope by default isn't good practice in embedded. Global scope isn't synonymous with static allocation, but unfortunately that goes over the head of many people. Best practice in embedded is to have locally scoped statically allocated data passed around by reference.
        craftinator 6y ago
        It really depends on the application. For smaller, more targetted embedded applications, global scope is fine. If every function needs to have access to a common set of variables, there's really no need to be passing references around.
        centimeter 6y ago
        Even if the application is tiny, that's no excuse. It makes it even easier to chuck everything into a single struct type. It's not like there's any performance gain to having globally scoped stuff on a modern compiler compared to passing references. One reason using global variables is bad practice is it makes testing harder. An unfortunately high percentage of embedded software doesn't have any sort of harness-based testing because it's written with globals spammed everywhere, which prevents you from using any kind of principled testing strategy where you mock out all the hardware dependencies. It's especially bad if there's globally defined MMIO stuff like "#DEFINE CCR1A (uint64_t)0x74FEA10". Good luck testing that!
- tastyminerals 6y ago
  And don't forget that "modern alternative" should boast as good as Lua C ffi which is a tough thing to beat. Should I mention luajit?
- astrobe_ 6y ago
  Oh yes, we need a modern powerful web-scalable professionally infrastructured alternative. Sorry for the sarcasm, but if you are thinking with theses words, you are thinking wrong.
  - pinopinopino 6y ago
    I feel your sentiment. Modern doesn't mean good perse.
- Rochus 6y ago
  There are a lot of alternatives. See https://github.com/hengestone/lua-languages https://github.com/hengestone/lua-languages. These languages use the Lua or LuaJIT VM as a backend, either as a Lua transpiler or a bytecode compiler.
- novemberisms 6y ago
  A lot of people who don't like Lua list "only having tables" as some sort of negative, but honestly I don't see how that is bad in any way. 1. Having only 1 data structure makes for a simpler, more elegant language. Once you understand tables, you understand everything you need to know about lua. 2. You could implement any other data structure with a table. * A table is basically a dictionary / map already * A table can be an array if you use numbers as keys. They don't even have to start at 1. * A table can easily be made into a set if you use the elements of the set as keys and 'true' as the values. * A table can be made into a proper OOP class with metatables * A table can use prototypical inheritance too * A table can act as a basic data record object Those using the language don't really miss having the more specific data structures.
  - theptip 6y ago
    In my experience, it took a bit of conceptual work to get used to the "Lua way", and that impedance mismatch would have been reduced if it shared more similarities with the other languages we were working with. Context is important IMO; if you're going to using a language as your primary development tool, then you'll get over that hump fairly quickly, and my objection is less relevant. But for our use-case (embedding Lua in a C application to have user-provided scripts drive our C library's callback hooks), the developers were primarily working in C and Python, and so most of us didn't use Lua often enough to really click with it. For our use-case, something a bit closer to Python or Java would have been much easier to grok, and therefore would have made our development easier and more productive. "Easy and more productive" is all I'm really looking for in a language, always within the context of the specific usecase of course. I'd be fine with dropping most of the sugar in Python or Java, but I'd be surprised if there were no "zero-cost abstractions" that could be added to Lua without making it too heavyweight for embedding.
cygx 6y ago
If such a comparison gets added, Wren[1] might also be of interest. [1] https://wren.io/ https://wren.io/
- ctas 6y ago
  The similarity to Gravity is astonishing.
  - deleted 6y ago
    [deleted]
- mythz 6y ago
  Wren and Bob Nystrom are called out as major inspirations: https://github.com/marcobambini/gravity#special-thanks https://github.com/marcobambini/gravity#special-thanks
- fallat 6y ago
  wren is so far my favorite small, simple language.
Rochus 6y ago
Lua is indeed difficult to beat in this respect. If you need performance you can even embedd LuaJIT with a footprint still far under one megabyte. And if you don't like the Lua syntax, there are already good alternatives,e.g. the statically/strongly typed https://github.com/rochus-keller/Oberon https://github.com/rochus-keller/Oberon which directly generates LuaJIT bytecode (based on https://github.com/rochus-keller/LjTools https://github.com/rochus-keller/LjTools). Here is a fairly complete list of languages compiling to Lua: https://github.com/hengestone/lua-languages https://github.com/hengestone/lua-languages. Gravity could be one of these if need be.
- zeotroph 6y ago
  LuaJIT development has effectively halted, and only supports Lua 5.1 (5.3 is current, 5.4 imminent). I get the feeling that Lua is slowly on its way out because the academic nature of it never meant it had to be more than "good enough" outside it's core strengths. I think they should have kept a super-light "classic" Lua where ~= still means !=, there are only tables, and all the other quirks (but also speed). Then add official, optional support for classes, lists, dicts, sets. This probably can all be built on top of setmetatable, so be pure lua, but at least it comes as one consistent standard library and not in the form of a fractured ecosystem. All the mentioned compiles-to-lua Projects tried something similar, but never gained significant traction, probably because of the lack of an official blessing.
  - Rochus 6y ago
    > LuaJIT development has effectively halted ... never meant it had to be more than "good enough" outside it's core strengths That's a wrong impression. Even the original author of LuaJIT still commits regularly and there are dozens of companies maintaining and using it in industrial scale applications, and there are a couple of forks which focus on specific use cases and are independently developed. Not to forget the hundreds of games using Lua as a scripting language. > only supports Lua 5.1 (5.3 is current, 5.4 imminent). Which is obviously enough for most people using it including me. I don't see any unique selling point which would force me to update to Lua 5.3 or higher. > and all the other quirks (but also speed). Well, do your research. LuaJIT is among the fastest JITs available (e.g. a factor ~1.5 faster in geometric mean than JS V8), but with a much smaller footprint.

vorpalhex 6y ago

As someone who just worked on a project where I embedded lua, that's exactly what I was looking for. Why would I want to choose this over lua and what's the pro/con matrix?

kevin_thibedeau 6y ago
0-based array indexing and local scoping by default.
- VWWHFSfQ 6y ago
  would have to do better than that
- rumanator 6y ago
  If that's the best you can come up with then I'm afraid there isn't much of a case to use this over lua.

theptip 6y ago

Agreed, Lua seems to be the de-facto standard here, as it's so lightweight to embed. But the language has some pretty janky rough edges (e.g. only having Tables and no other data structures) so a modern alternative would be nice.

runawaybottle 6y ago
Isn’t that what makes it lightweight? It literally doesn’t have the extra weight.
tastyminerals 6y ago
Once you get to know Lua tables and then metatables, you will question the existence of different data structures :)
- jmiskovic 6y ago
  Yes, Lua tables are incredibly versatile tool. I'm not a fan of global-scope-by-default and of verbosity, but other than that it's a fantastic language.
  - craftinator 6y ago
    I think global by default is one of the reason Lua shines in the embedded world. Not many other arenas where that is good practice.
    - zem 6y ago
      editor scripting, perhaps
    - centimeter 6y ago
      Global scope by default isn't good practice in embedded. Global scope isn't synonymous with static allocation, but unfortunately that goes over the head of many people. Best practice in embedded is to have locally scoped statically allocated data passed around by reference.
      - craftinator 6y ago
        It really depends on the application. For smaller, more targetted embedded applications, global scope is fine. If every function needs to have access to a common set of variables, there's really no need to be passing references around.
        centimeter 6y ago
        Even if the application is tiny, that's no excuse. It makes it even easier to chuck everything into a single struct type. It's not like there's any performance gain to having globally scoped stuff on a modern compiler compared to passing references. One reason using global variables is bad practice is it makes testing harder. An unfortunately high percentage of embedded software doesn't have any sort of harness-based testing because it's written with globals spammed everywhere, which prevents you from using any kind of principled testing strategy where you mock out all the hardware dependencies. It's especially bad if there's globally defined MMIO stuff like "#DEFINE CCR1A (uint64_t)0x74FEA10". Good luck testing that!
tastyminerals 6y ago
And don't forget that "modern alternative" should boast as good as Lua C ffi which is a tough thing to beat. Should I mention luajit?
astrobe_ 6y ago
Oh yes, we need a modern powerful web-scalable professionally infrastructured alternative. Sorry for the sarcasm, but if you are thinking with theses words, you are thinking wrong.
- pinopinopino 6y ago
  I feel your sentiment. Modern doesn't mean good perse.
Rochus 6y ago
There are a lot of alternatives. See https://github.com/hengestone/lua-languages https://github.com/hengestone/lua-languages. These languages use the Lua or LuaJIT VM as a backend, either as a Lua transpiler or a bytecode compiler.
novemberisms 6y ago
A lot of people who don't like Lua list "only having tables" as some sort of negative, but honestly I don't see how that is bad in any way. 1. Having only 1 data structure makes for a simpler, more elegant language. Once you understand tables, you understand everything you need to know about lua. 2. You could implement any other data structure with a table. * A table is basically a dictionary / map already * A table can be an array if you use numbers as keys. They don't even have to start at 1. * A table can easily be made into a set if you use the elements of the set as keys and 'true' as the values. * A table can be made into a proper OOP class with metatables * A table can use prototypical inheritance too * A table can act as a basic data record object Those using the language don't really miss having the more specific data structures.
- theptip 6y ago
  In my experience, it took a bit of conceptual work to get used to the "Lua way", and that impedance mismatch would have been reduced if it shared more similarities with the other languages we were working with. Context is important IMO; if you're going to using a language as your primary development tool, then you'll get over that hump fairly quickly, and my objection is less relevant. But for our use-case (embedding Lua in a C application to have user-provided scripts drive our C library's callback hooks), the developers were primarily working in C and Python, and so most of us didn't use Lua often enough to really click with it. For our use-case, something a bit closer to Python or Java would have been much easier to grok, and therefore would have made our development easier and more productive. "Easy and more productive" is all I'm really looking for in a language, always within the context of the specific usecase of course. I'd be fine with dropping most of the sugar in Python or Java, but I'd be surprised if there were no "zero-cost abstractions" that could be added to Lua without making it too heavyweight for embedding.

cygx 6y ago

If such a comparison gets added, Wren[1] might also be of interest. [1] https://wren.io/ https://wren.io/

ctas 6y ago
The similarity to Gravity is astonishing.
- deleted 6y ago
  [deleted]
mythz 6y ago
Wren and Bob Nystrom are called out as major inspirations: https://github.com/marcobambini/gravity#special-thanks https://github.com/marcobambini/gravity#special-thanks
fallat 6y ago
wren is so far my favorite small, simple language.

Rochus 6y ago

Lua is indeed difficult to beat in this respect. If you need performance you can even embedd LuaJIT with a footprint still far under one megabyte. And if you don't like the Lua syntax, there are already good alternatives,e.g. the statically/strongly typed https://github.com/rochus-keller/Oberon https://github.com/rochus-keller/Oberon which directly generates LuaJIT bytecode (based on https://github.com/rochus-keller/LjTools https://github.com/rochus-keller/LjTools). Here is a fairly complete list of languages compiling to Lua: https://github.com/hengestone/lua-languages https://github.com/hengestone/lua-languages. Gravity could be one of these if need be.

zeotroph 6y ago
LuaJIT development has effectively halted, and only supports Lua 5.1 (5.3 is current, 5.4 imminent). I get the feeling that Lua is slowly on its way out because the academic nature of it never meant it had to be more than "good enough" outside it's core strengths. I think they should have kept a super-light "classic" Lua where ~= still means !=, there are only tables, and all the other quirks (but also speed). Then add official, optional support for classes, lists, dicts, sets. This probably can all be built on top of setmetatable, so be pure lua, but at least it comes as one consistent standard library and not in the form of a fractured ecosystem. All the mentioned compiles-to-lua Projects tried something similar, but never gained significant traction, probably because of the lack of an official blessing.
- Rochus 6y ago
  > LuaJIT development has effectively halted ... never meant it had to be more than "good enough" outside it's core strengths That's a wrong impression. Even the original author of LuaJIT still commits regularly and there are dozens of companies maintaining and using it in industrial scale applications, and there are a couple of forks which focus on specific use cases and are independently developed. Not to forget the hundreds of games using Lua as a scripting language. > only supports Lua 5.1 (5.3 is current, 5.4 imminent). Which is obviously enough for most people using it including me. I don't see any unique selling point which would force me to update to Lua 5.3 or higher. > and all the other quirks (but also speed). Well, do your research. LuaJIT is among the fastest JITs available (e.g. a factor ~1.5 faster in geometric mean than JS V8), but with a much smaller footprint.