4 ms·

My humble opinion is that most applications that need scripting should just embed JavaScript. It has a massive advantage in the existing ecosystem. People don’

by pavlov 2y ago

My humble opinion is that most applications that need scripting should just embed JavaScript. It has a massive advantage in the existing ecosystem. People don’t always love it, but millions of them already know it. You don’t need to re-learn array indexing and nil termination quirks and the dozens of other things where Lua is subtly different in ways that you’ll find out at runtime. There are JS engines in all sizes, from tiny interpreters to world-leading JIT performance monsters. And most operating systems nowadays ship with a high-quality engine and embedding framework that you can access without installing anything, like JavaScriptCore on the Apple platforms. Do your users a favor and just use the boring standard language instead of making them learn a completely new one that doesn’t offer meaningful practical benefits for them. It’s probably not as much fun for you, but you’ll save time for both the users and yourself in the end.

Demiurge 2y ago
On one hand, you do have JavaScript ubiquity, on the other hand, you have the JavaScript "WTF" equality and typing conversion matrix, "WTF" scoping, and dozens of other foot guns that Lua doesn't have. Some people would rather everyone learned Lua subtle differences and wrote less buggy code. I've had to use for the web for 20 years, and if I have any choice, I would avoid it. Anyway, every language has some fans, and I don't mean to dismiss them, but ubiquity is not the top priority, all the time.
- therein 2y ago
  There is the equality gotchas on JavaScript but then you have 1-indexed arrays in Lua, which is a footgun that I know exists, I try to avoid shooting myself in the foot with it but I keep doing it. It is beyond a footgun, more like a footgun concealed as a shoehorn. Either way I find embedding a Lua VM into a project so much easier than embedding a Javascript one.
  - kragen 2y ago
    Which JS VMs have you tried embedding? People in this thread have suggested https://github.com/Moddable-OpenSource/moddable https://github.com/Moddable-OpenSource/moddable, https://bellard.org/quickjs/ https://bellard.org/quickjs/, and https://duktape.org/ https://duktape.org/, but I haven't tried any of them.
  - Demiurge 2y ago
    Indexing, I give you this one... I think it was intended as some kind of a gift to a "non programmer", a choice many other older language made, by the history decided to go another way, unfortunately for Lua. Still, I haven't had any issues adjusting to this one, personally. It seems kind of like Python whitespacing, I think I forget about it.
- leptons 2y ago
  The only people saying "WTF" about Javascript are people who haven't taken the time to learn how to use it effectively. There are "WTF" things about every language, not just Javascript. Noobs are going to find the footguns in any language. Every language can be misused. I've been using Javascript over 20 years and have never thought it was any worse than any other language. Yes, it's dynamic, and yes, you can do stupid things with that dynamism, but for someone who actually knows how to use it, it's quite easy to work with. I recently started using Lua and I'm not impressed at all. It's just another language, it's really up to the programmer what can be done with it, just like Javascript.
  - 3a2d29 2y ago
    This is the common arguement used by people defending languages with tons of footguns. If this is true, why not write everything in C++? Javscript includes so many footguns that people know are bad (see the billion of examples of different types being added and getting random answers). Every langauge has some difficult parts, pretending that means any amount is fine is crazy. Javascript has earned its reputation.
    - leptons 2y ago
      >(see the billion of examples of different types being added and getting random answers) Almost every "footgun" people cite about Javascript is something that would never be written as working code, by any competent programmer - they are "WTF" in that the person writing the "gotcha" has to go way outside of normal programming behavior to get the "WTF" result. Most of these "WTF" examples should be taken with a grain of salt. If you're expecting to "WTF" about Javascript's type inference/coercion, that works according to some logical rules. https://media.geeksforgeeks.org/wp-content/uploads/advanced-javascript-backend-basics.png https://media.geeksforgeeks.org/wp-content/uploads/advanced-... This matrix should be pretty easy to understand. Yes some things might seem weird like [[]] == false, and [1] == true, but nobody should be writing code like that, it's just illogical to do anything this way and I don't consider it to be a "gotcha". "Just because you can, doesn't mean you should" can be said about footguns in every language. Yes, there are "WTF"s, but just like if I were to write a C++ "WTF", it wouldn't be something that most people would be tripped up by unless they were specifically looking for a way to say "WTF" about the language. These "javascript sucks" internet arguments have persisted for decades, and it's always complaints about the language that are citing unreasonable examples to prove a point that a programming language has some rough edges. Every programming language has some rough edges. Javascript maybe has more footguns than some other languages because it is so dynamic, and the dynamism has its benefits too that other languages don't have. I do like it and I use it effectively, YMMV. People just seem to be specifically mad at Javascript because it's so popular and was made so by being the defacto standard for web browsers. It's part jealousy and part frustration that their favorite programming language isn't the one that web browsers include by default.
- IshKebab 2y ago
  Fortunately most of JavaScript's WTFs are avoidable (though I do wish they'd add a "really strict;" mode that actually removed them).
  - Demiurge 2y ago
    Yeah, that would be great. I remember this was helpful in Perl, and ES6 days.
- wruza 2y ago
  JavaScript has very nice scoping compared to Lua. Js needs no forwards which in Lua turn into ugly “local foo; … … … foo = function()…end”. All functions are “hoisted” by default. Js also uses “export”s or “module.exports[…]” instead of returning a symbol table, which allows cross-referencing. Js has a function scope (var) together with local scoping. Js doesn’t allow accidental shadowing in the same scope. Lua: local x; local x; silently creates two variables, good luck debugging that closure. Js type coercion is only insane in the parts where operation itself makes zero sense. Please don’t tell me that ![0] or [] + {} makes sense to you or that you use them in other languages. Or that s+n and n+s seems safe everywhere except in js. Js has a ternary operator and ?? ?. ??= operator group. Lua only has that “and-or” crutch and “not X” which returns true only for nil and false. Js “…arr” is a first class citizen while in Lua “…” decays into its last value if you want to follow it. Js (normally) ordered properties system is much more convenient in dev and debug time than an unordered mess of meta-hashtables. Js doesn’t require you to { myPropertyHere = gotSomeObject.myPropertyHere, … IllRepeatThisAsManyTimesAsNeeded = gotSomeObject.causeWhyNot, } gotSomeObject.someNumericField = gotSomeObject.someNumericField + 1 which is extremely abhorrent DX in 2024.
SoftTalker 2y ago
This probably makes more sense in 2024 but for many years JavaScript was not a serious option. I wasn't until the mid-late 2000's that it started to get traction as an application language and had any way to run it outside of a web browser. Lua as an embedded language already had over a decade head start.
- leptons 2y ago
  Netscape had javascript running server-side in 1995, only a couple years after Lua was created. So no, Lua did not have "over a decade head start", it had 1 year. Microsoft also had server-side JS, and still do. Active Server Pages (ASP) were scriptable with javascript since 1996. Microsoft's JScript.net has been around since 2002 (even if not well supported or maintained by M$, it still works). I've written web back-ends, Windows desktop applications, and even .dlls with JScript.net as far back as 2003. Javascript has been Adobe's scripting engine for Photoshop since 2005. Sony chose Javascript for Vegas Video's scripting language in 2003. Javascript has so many uses outside of a web browser, and has for a very long time.
  - SoftTalker 2y ago
    Yes but for the first 10 years (1995 - ~2005) JavaScript was not taken seriously as an application language in most dev shops. Active Server Pages were overwhelmingly coded in VBScript. JavaScript was used in little snippets in "onBlur" attributes to do client-side validation of fields on a form, pop up "alert" boxes, and enable submit buttons. It wasn't until XMLHttp and prototype.js and jquery and stuff like that came along that mainstream developers started to understand what JavaScript was capable of.
    - leptons 2y ago
      I guess I wasn't a "mainstream" developer in the 1990's? Before XMLHTTPRequest, I was using iframes to asynchronously load content into the browser, essentially accomplishing the same thing before "AJAX" was a thing. We were doing long-polling before there was websockets. I was using Javascript and CSS to create "DHTML" SPAs before XMLHTTPRequest, with Javascript for front-end and back-end. You either know the potential of the tools that are available, or you don't. But I guess my anecdotal experience doesn't matter, because I wasn't a "mainstream" developer? From my point of view, everyone else was missing out on using one language for front-end and back-end. Context switching has a real cost in terms of developer burnout, and it's something I've happily avoided for 25 years.
Groxx 2y ago
For cases where you can realistically include a full v8 in your project, yea - that seems fairly reasonable nowadays. Javascript took an extremely high-complexity, high-cost, and nearly-all-effort-in-just-two-impls-for-over-a-decade route to get to the current (stunning) performance though. How do small-scale embedded interpreters stack up? That's what many things that aren't Electron apps will be using. I ask this honestly, to be clear - I'm not sure how they stack up. I know Lua has historically targeted and dominated this area so I'd expect it to win, but I have not seen any data and I largely agree - JS is a massively better development environment now, and I would love to choose it. Everything I can find pits it against v8, and that's kinda like comparing the performance of a bike against a train - they are so different in many situations that it's meaningless. Otherwise I'd probably choose WASM today, or maybe docker containers where performance and platform needs isn't an issue.
- CharlesW 2y ago
  > How do small-scale embedded interpreters stack up? Moddable's XS runtime is a wonder, with 99%+ ES2023 conformance even on devices running at 80 kHz with 45 KB of free memory. https://github.com/Moddable-OpenSource/moddable https://github.com/Moddable-OpenSource/moddable QuickJS has somewhat higher requirements, but also a great candidate for embeddable mobile and desktop applications, and is well-regarded. https://bellard.org/quickjs/ https://bellard.org/quickjs/
krapp 2y ago
"most people should use the things I use and am familiar with" is a common opinion but you should realize that between Javascript and Lua, Lua is the boring standard language in this context. Also there are whole books written on the quirks you need to master with Javascript. Lua has its rough edges but it's a much simpler language, so there are far fewer of them.
- pavlov 2y ago
  What’s the end-user segment where Lua is more widely known than JavaScript? Game dev, possibly (even that seems highly debatable). But the article was making the case that Lua should be more widely used outside of that niche.
  - mikey_p 2y ago
    Doesn't matter if it's widely known, it honestly is much nicer to work with than Javascript and is being used as it is intended, instead of being a half-baked language designed in a hurry, to work in a browser, that got repurposed as a general purpose scripting language later.
- mardifoufs 2y ago
  Lua has a ton of sharp edges, they just don't manifest themselves as much as with JavaScript since JS has a different "typical use case" and aren't as often discussed. Writing user facing UIs, with all that it entails, is a great way to uncover and experience all possible sharp edges. And a lot of the issues with JavaScript just wouldn't matter for an "embedded scripting engine" use case imo.
2OEH8eoCRo0 2y ago
My exact thought when trying to program my Logitech mouse (which uses Lua). I also think 9 out of 10 languages are overrated and we have far too many.
kragen 2y ago
Lua 5.2 is 15000 lines of portable ANSI C. On amd64 the Debian default configuration of the interpreter compiles to a 950KiB executable that strips to 224K. I think reduced configurations can go below 100K. It doesn't start extra threads, demand a thread of its own, or have tricky memory management demands. What JS interpreter would you recommend for cases where that's a good fit? Something that's less than a megabyte and can be compiled to run on weird architectures.
- Vogtinator 2y ago
  https://duktape.org https://duktape.org is in a similar ballpark.
  - kragen 2y ago
    This does look great! Unfortunately it looks like it'll be hard for me to build it; it's yet another project that got fucked over by the Python community's irresponsibility.
    - tecleandor 2y ago
      Why is that? I think I haven't heard of Duktape before, so I don't have the background for whatever happened.
      - kragen 2y ago
        Its build system apparently depends on Python 2.
        rcarmo 2y ago
        No it doesn't. People who complain about that clearly haven't actually checked - there's a warning in the old configuration scripts as well: * Duktape python tooling is obsolete, migrate to JS-based tooling! *
        2y ago
DanielHB 2y ago
Lua used to be very popular for embedding because the runtime was minuscule so it could run in very constrained environments (like old consoles). This is mostly a non-issue these days though. JS and Lua are very similar feature-wise and I imagine Lua hasn't gotten the massive JIT runtime optimizations that JS has, so JS seems a far better choice these days.
- Isogash 2y ago
  Once you reach LuaJIT levels of performance though it's not like you need more. If you're doing a huge amount of heavy lifting in your embedded runtime then you've probably designed the application wrong. The fat better arguments are that it's more common and there are more libraries.
  - DanielHB 2y ago
    Yeah that is a good point, I also imagine lua is far easier (build/linking) to add into your application compared to pulling V8 or JavascriptCore. So if you only need a small language to do a couple thousand lines of code in than it still might be a better choice. But for larger projects JS still seems better due to the ecosystem and knowledge available. But if you compare some games like baldurs gate 2 where most of the event logic and quest state is in the scripting language, then maybe it is worth spending the time to add JS. But if it is like Civilization 6 where only small stuff like UI and I/O mapping is in the scripting language then it is a different matter.
tecleandor 2y ago
The problem I have with Javascript is that, for some reason (mostly, my lack of practice), looks really difficult to me. I'm no developer, I do Linux and some bash and Python, and Lua looks "familiar" to me, so I can quickly pull up something simple. With Javascript everything looks so alien to me, and it's a pity because there is lots of things that run Javascript (functions in the cloud and the like).
danbreuer 2y ago
I disagree for the same reason -- how quickly the language can be picked up and used productively. Due to Lua's small footprint, a novice user can skim through the Lua docs and walk away with a useful mental model for most of the language. This is not the case for Javascript, which has far more syntax and many duplicated subtly-different features (var/let, class/plain objects, this definition depending on lambda syntax). Not something easily grasped by a new user. And sure, there are many Javascript snippets floating around and its possible to pick up some subset of Javascript by osmosis. However, this approach leads to a "poke it with a stick until it works, while understanding nothing and slowly going mad" UX from what I've seen. Which is not something I would aim for in the kind of productivity tools embedded scripting languages are used in.-- I find these tools are far more satisfying and productive to use when you have a simple mental model which clicks in place after a bit of effort up front, letting you work after without having to consult docs for every step. (Of course this is not an issue if you're targetting only developers proficient with Javascript as users, but this is not the case for most applications outside of the webdev space.)

by pavlov 2y ago

Demiurge 2y ago

On one hand, you do have JavaScript ubiquity, on the other hand, you have the JavaScript "WTF" equality and typing conversion matrix, "WTF" scoping, and dozens of other foot guns that Lua doesn't have. Some people would rather everyone learned Lua subtle differences and wrote less buggy code. I've had to use for the web for 20 years, and if I have any choice, I would avoid it. Anyway, every language has some fans, and I don't mean to dismiss them, but ubiquity is not the top priority, all the time.

therein 2y ago
There is the equality gotchas on JavaScript but then you have 1-indexed arrays in Lua, which is a footgun that I know exists, I try to avoid shooting myself in the foot with it but I keep doing it. It is beyond a footgun, more like a footgun concealed as a shoehorn. Either way I find embedding a Lua VM into a project so much easier than embedding a Javascript one.
- kragen 2y ago
  Which JS VMs have you tried embedding? People in this thread have suggested https://github.com/Moddable-OpenSource/moddable https://github.com/Moddable-OpenSource/moddable, https://bellard.org/quickjs/ https://bellard.org/quickjs/, and https://duktape.org/ https://duktape.org/, but I haven't tried any of them.
- Demiurge 2y ago
  Indexing, I give you this one... I think it was intended as some kind of a gift to a "non programmer", a choice many other older language made, by the history decided to go another way, unfortunately for Lua. Still, I haven't had any issues adjusting to this one, personally. It seems kind of like Python whitespacing, I think I forget about it.
leptons 2y ago
The only people saying "WTF" about Javascript are people who haven't taken the time to learn how to use it effectively. There are "WTF" things about every language, not just Javascript. Noobs are going to find the footguns in any language. Every language can be misused. I've been using Javascript over 20 years and have never thought it was any worse than any other language. Yes, it's dynamic, and yes, you can do stupid things with that dynamism, but for someone who actually knows how to use it, it's quite easy to work with. I recently started using Lua and I'm not impressed at all. It's just another language, it's really up to the programmer what can be done with it, just like Javascript.
- 3a2d29 2y ago
  This is the common arguement used by people defending languages with tons of footguns. If this is true, why not write everything in C++? Javscript includes so many footguns that people know are bad (see the billion of examples of different types being added and getting random answers). Every langauge has some difficult parts, pretending that means any amount is fine is crazy. Javascript has earned its reputation.
  - leptons 2y ago
    >(see the billion of examples of different types being added and getting random answers) Almost every "footgun" people cite about Javascript is something that would never be written as working code, by any competent programmer - they are "WTF" in that the person writing the "gotcha" has to go way outside of normal programming behavior to get the "WTF" result. Most of these "WTF" examples should be taken with a grain of salt. If you're expecting to "WTF" about Javascript's type inference/coercion, that works according to some logical rules. https://media.geeksforgeeks.org/wp-content/uploads/advanced-javascript-backend-basics.png https://media.geeksforgeeks.org/wp-content/uploads/advanced-... This matrix should be pretty easy to understand. Yes some things might seem weird like [[]] == false, and [1] == true, but nobody should be writing code like that, it's just illogical to do anything this way and I don't consider it to be a "gotcha". "Just because you can, doesn't mean you should" can be said about footguns in every language. Yes, there are "WTF"s, but just like if I were to write a C++ "WTF", it wouldn't be something that most people would be tripped up by unless they were specifically looking for a way to say "WTF" about the language. These "javascript sucks" internet arguments have persisted for decades, and it's always complaints about the language that are citing unreasonable examples to prove a point that a programming language has some rough edges. Every programming language has some rough edges. Javascript maybe has more footguns than some other languages because it is so dynamic, and the dynamism has its benefits too that other languages don't have. I do like it and I use it effectively, YMMV. People just seem to be specifically mad at Javascript because it's so popular and was made so by being the defacto standard for web browsers. It's part jealousy and part frustration that their favorite programming language isn't the one that web browsers include by default.
IshKebab 2y ago
Fortunately most of JavaScript's WTFs are avoidable (though I do wish they'd add a "really strict;" mode that actually removed them).
- Demiurge 2y ago
  Yeah, that would be great. I remember this was helpful in Perl, and ES6 days.
wruza 2y ago
JavaScript has very nice scoping compared to Lua. Js needs no forwards which in Lua turn into ugly “local foo; … … … foo = function()…end”. All functions are “hoisted” by default. Js also uses “export”s or “module.exports[…]” instead of returning a symbol table, which allows cross-referencing. Js has a function scope (var) together with local scoping. Js doesn’t allow accidental shadowing in the same scope. Lua: local x; local x; silently creates two variables, good luck debugging that closure. Js type coercion is only insane in the parts where operation itself makes zero sense. Please don’t tell me that ![0] or [] + {} makes sense to you or that you use them in other languages. Or that s+n and n+s seems safe everywhere except in js. Js has a ternary operator and ?? ?. ??= operator group. Lua only has that “and-or” crutch and “not X” which returns true only for nil and false. Js “…arr” is a first class citizen while in Lua “…” decays into its last value if you want to follow it. Js (normally) ordered properties system is much more convenient in dev and debug time than an unordered mess of meta-hashtables. Js doesn’t require you to { myPropertyHere = gotSomeObject.myPropertyHere, … IllRepeatThisAsManyTimesAsNeeded = gotSomeObject.causeWhyNot, } gotSomeObject.someNumericField = gotSomeObject.someNumericField + 1 which is extremely abhorrent DX in 2024.

SoftTalker 2y ago

This probably makes more sense in 2024 but for many years JavaScript was not a serious option. I wasn't until the mid-late 2000's that it started to get traction as an application language and had any way to run it outside of a web browser. Lua as an embedded language already had over a decade head start.

leptons 2y ago
Netscape had javascript running server-side in 1995, only a couple years after Lua was created. So no, Lua did not have "over a decade head start", it had 1 year. Microsoft also had server-side JS, and still do. Active Server Pages (ASP) were scriptable with javascript since 1996. Microsoft's JScript.net has been around since 2002 (even if not well supported or maintained by M$, it still works). I've written web back-ends, Windows desktop applications, and even .dlls with JScript.net as far back as 2003. Javascript has been Adobe's scripting engine for Photoshop since 2005. Sony chose Javascript for Vegas Video's scripting language in 2003. Javascript has so many uses outside of a web browser, and has for a very long time.
- SoftTalker 2y ago
  Yes but for the first 10 years (1995 - ~2005) JavaScript was not taken seriously as an application language in most dev shops. Active Server Pages were overwhelmingly coded in VBScript. JavaScript was used in little snippets in "onBlur" attributes to do client-side validation of fields on a form, pop up "alert" boxes, and enable submit buttons. It wasn't until XMLHttp and prototype.js and jquery and stuff like that came along that mainstream developers started to understand what JavaScript was capable of.
  - leptons 2y ago
    I guess I wasn't a "mainstream" developer in the 1990's? Before XMLHTTPRequest, I was using iframes to asynchronously load content into the browser, essentially accomplishing the same thing before "AJAX" was a thing. We were doing long-polling before there was websockets. I was using Javascript and CSS to create "DHTML" SPAs before XMLHTTPRequest, with Javascript for front-end and back-end. You either know the potential of the tools that are available, or you don't. But I guess my anecdotal experience doesn't matter, because I wasn't a "mainstream" developer? From my point of view, everyone else was missing out on using one language for front-end and back-end. Context switching has a real cost in terms of developer burnout, and it's something I've happily avoided for 25 years.

Groxx 2y ago

For cases where you can realistically include a full v8 in your project, yea - that seems fairly reasonable nowadays. Javascript took an extremely high-complexity, high-cost, and nearly-all-effort-in-just-two-impls-for-over-a-decade route to get to the current (stunning) performance though. How do small-scale embedded interpreters stack up? That's what many things that aren't Electron apps will be using. I ask this honestly, to be clear - I'm not sure how they stack up. I know Lua has historically targeted and dominated this area so I'd expect it to win, but I have not seen any data and I largely agree - JS is a massively better development environment now, and I would love to choose it. Everything I can find pits it against v8, and that's kinda like comparing the performance of a bike against a train - they are so different in many situations that it's meaningless. Otherwise I'd probably choose WASM today, or maybe docker containers where performance and platform needs isn't an issue.

CharlesW 2y ago
> How do small-scale embedded interpreters stack up? Moddable's XS runtime is a wonder, with 99%+ ES2023 conformance even on devices running at 80 kHz with 45 KB of free memory. https://github.com/Moddable-OpenSource/moddable https://github.com/Moddable-OpenSource/moddable QuickJS has somewhat higher requirements, but also a great candidate for embeddable mobile and desktop applications, and is well-regarded. https://bellard.org/quickjs/ https://bellard.org/quickjs/

krapp 2y ago

"most people should use the things I use and am familiar with" is a common opinion but you should realize that between Javascript and Lua, Lua is the boring standard language in this context. Also there are whole books written on the quirks you need to master with Javascript. Lua has its rough edges but it's a much simpler language, so there are far fewer of them.

pavlov 2y ago
What’s the end-user segment where Lua is more widely known than JavaScript? Game dev, possibly (even that seems highly debatable). But the article was making the case that Lua should be more widely used outside of that niche.
- mikey_p 2y ago
  Doesn't matter if it's widely known, it honestly is much nicer to work with than Javascript and is being used as it is intended, instead of being a half-baked language designed in a hurry, to work in a browser, that got repurposed as a general purpose scripting language later.
mardifoufs 2y ago
Lua has a ton of sharp edges, they just don't manifest themselves as much as with JavaScript since JS has a different "typical use case" and aren't as often discussed. Writing user facing UIs, with all that it entails, is a great way to uncover and experience all possible sharp edges. And a lot of the issues with JavaScript just wouldn't matter for an "embedded scripting engine" use case imo.

2OEH8eoCRo0 2y ago

My exact thought when trying to program my Logitech mouse (which uses Lua). I also think 9 out of 10 languages are overrated and we have far too many.

kragen 2y ago

Lua 5.2 is 15000 lines of portable ANSI C. On amd64 the Debian default configuration of the interpreter compiles to a 950KiB executable that strips to 224K. I think reduced configurations can go below 100K. It doesn't start extra threads, demand a thread of its own, or have tricky memory management demands. What JS interpreter would you recommend for cases where that's a good fit? Something that's less than a megabyte and can be compiled to run on weird architectures.

Vogtinator 2y ago
https://duktape.org https://duktape.org is in a similar ballpark.
- kragen 2y ago
  This does look great! Unfortunately it looks like it'll be hard for me to build it; it's yet another project that got fucked over by the Python community's irresponsibility.
  - tecleandor 2y ago
    Why is that? I think I haven't heard of Duktape before, so I don't have the background for whatever happened.
    - kragen 2y ago
      Its build system apparently depends on Python 2.
      - rcarmo 2y ago
        No it doesn't. People who complain about that clearly haven't actually checked - there's a warning in the old configuration scripts as well: * Duktape python tooling is obsolete, migrate to JS-based tooling! *
        2y ago

DanielHB 2y ago

Lua used to be very popular for embedding because the runtime was minuscule so it could run in very constrained environments (like old consoles). This is mostly a non-issue these days though. JS and Lua are very similar feature-wise and I imagine Lua hasn't gotten the massive JIT runtime optimizations that JS has, so JS seems a far better choice these days.

Isogash 2y ago
Once you reach LuaJIT levels of performance though it's not like you need more. If you're doing a huge amount of heavy lifting in your embedded runtime then you've probably designed the application wrong. The fat better arguments are that it's more common and there are more libraries.
- DanielHB 2y ago
  Yeah that is a good point, I also imagine lua is far easier (build/linking) to add into your application compared to pulling V8 or JavascriptCore. So if you only need a small language to do a couple thousand lines of code in than it still might be a better choice. But for larger projects JS still seems better due to the ecosystem and knowledge available. But if you compare some games like baldurs gate 2 where most of the event logic and quest state is in the scripting language, then maybe it is worth spending the time to add JS. But if it is like Civilization 6 where only small stuff like UI and I/O mapping is in the scripting language then it is a different matter.

tecleandor 2y ago

The problem I have with Javascript is that, for some reason (mostly, my lack of practice), looks really difficult to me. I'm no developer, I do Linux and some bash and Python, and Lua looks "familiar" to me, so I can quickly pull up something simple. With Javascript everything looks so alien to me, and it's a pity because there is lots of things that run Javascript (functions in the cloud and the like).

danbreuer 2y ago

I disagree for the same reason -- how quickly the language can be picked up and used productively. Due to Lua's small footprint, a novice user can skim through the Lua docs and walk away with a useful mental model for most of the language. This is not the case for Javascript, which has far more syntax and many duplicated subtly-different features (var/let, class/plain objects, this definition depending on lambda syntax). Not something easily grasped by a new user. And sure, there are many Javascript snippets floating around and its possible to pick up some subset of Javascript by osmosis. However, this approach leads to a "poke it with a stick until it works, while understanding nothing and slowly going mad" UX from what I've seen. Which is not something I would aim for in the kind of productivity tools embedded scripting languages are used in.-- I find these tools are far more satisfying and productive to use when you have a simple mental model which clicks in place after a bit of effort up front, letting you work after without having to consult docs for every step. (Of course this is not an issue if you're targetting only developers proficient with Javascript as users, but this is not the case for most applications outside of the webdev space.)