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.

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.

Which JS VMs have you tried embedding? People in this thread have suggested https://github.com/Moddable-OpenSource/moddable, https://bellard.org/quickjs/, and https://duktape.org/, but I haven't tried any of them.

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.

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.

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.

>(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-...

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.

Agreed. I think a lot of the "classic" footguns are picked up by current-day linters/AI/code-assists anyway, so even if you do somehow end up writing [[]]==false legitimately (explicitly or implicitly), you'll probably get a squiggly warning about it on your IDE immediately warning you.

For better or worse, JavaScript is the Lingua Franca of modern programming - you have a high-performance runtime environment pre-installed on basically anything, and readily installed on greybeard boxen if you are that way inclined . It is my "go to" for all hobby projects, frontend and backend. So versatile and a genuine joy to code in.

This sounds like you haven't dealt with much moderately complex code in JavaScript. It sounds like you've never run into a situation where innocuous-looking code like

  if (isAuthenticated)
  {
    ...
  }

behaves strangely and it takes you hours to track down in debugging, only to find that somewhere else in the code, isAuthenticated was assigned an array and it was assumed it could be treated as a Boolean that would be false if and only if the array was empty. Turns out sometimes the value is [[]] and it gets treated as false unexpectedly.

In any reasonable language, even a dynamically typed one, this should just be a type error because it's not a Boolean, but JavaScript decides to do something almost certainly unwanted. This is the real source of the complaints, not the fact that you can write “[[]]==false” on the console and laugh at the results.

>only to find that somewhere else in the code, isAuthenticated was assigned an array

That isn't "moderately complex code", that's completely stupid code and you deserve the grief if you are willy-nilly setting a boolean as an array. Maybe learning the difference between a bool and an array is something you should have done earlier in your programming journey.

Also love how you assume I've never worked on "moderately complex code" as a slight on me, when I've been writing software for over 40 years - just because I don't do stupid shit like assigning an array to a boolean variable does not i dicate I've "never worked on moderately complex code". That's some kind of gatekeeping troll.

>any reasonable language

I'm really not sure how stupid you have to be to assign an array to isAuthenticated. No, it is not something I have ever done in any language, because I'm not an idiot. YMMV.

> This is the real source of the complaints,

The complaints come from people doing stupid shit to themselves. It was easily avoidable and they got mad at the language?? Should we blame the language for every stupid thing people do with it? Will you also blame English for letting you write an obviously stupid comment?

Lua feels and acts like a worse javascript. Yes the runtime can make the memory footprint really small, but manipulation and validation of the crappy list/table structures makes the implementations miserably large. I've only written about a million lines of it (literally), so I'm pretty set in my opinion.

Python is also dynamic, but it doesn't let you do things like (1 + "a"), for example.

Okey, so the first thing everyone should learn is not to use "==" but use "===". Or, perhaps, just use TypeScript, right? I think that's what people call "effective JavaScript" these days.

Quite a lot can be built reliably with Javascript following only "use ===". YMMV. Typescript doesn't solve much unless you use it religiously (and few people really do), it still allows for all kinds of "gotchas" if you want to write "gotchas" with it.

Fortunately most of JavaScript's WTFs are avoidable (though I do wish they'd add a "really strict;" mode that actually removed them).

Yeah, that would be great. I remember this was helpful in Perl, and ES6 days.

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.

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.

> 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

QuickJS has somewhat higher requirements, but also a great candidate for embeddable mobile and desktop applications, and is well-regarded. https://bellard.org/quickjs/

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.

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.

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.

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.

"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.

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.

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.

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.

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.

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.

https://duktape.org is in a similar ballpark.

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.

Why is that? I think I haven't heard of Duktape before, so I don't have the background for whatever happened.

Its build system apparently depends on Python 2.

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! *

I was looking at the example build configuration scripts on the project home page. Not somewhere linked from the home page, actually inline code on the page. Today! Literally as I'm writing this comment, it says:

  $ python2 duktape-2.6.0/tools/configure.py --output-directory src-duktape \
      -UDUK_USE_ES6_PROXY

I'm glad to hear my impression that there was no other build system was wrong!

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.

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.

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.

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).

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.)