Comment by wruza
1 year ago
Lua is not underrated. It’s how many now, still 4(?) different languages which continue to suicide after a few years, all with cringe [re]design decisions, half-assed mechanics and lack of convenience that authors refuse to address. I spent many years on it (embedding, metaprogramming, all the deep things) and it is one of my biggest regrets in the choice of tech. The amount of effort you’ll put into not sliding out of this crazy ride nullifies all the promises of easyness, which is limited to trivial things anyway and explodes with complexity in any non-trivial data exchange. Its only upside is low footprint, but I fail to see where it matters today (apart from nodemcu whose active users could probably fit in one closet).
https://github.com/nodemcu/nodemcu-firmware
Based on Lua 5.1.4 or Lua 5.3 but without debug, io, os and (most of the) math modules
As expected, they didn’t bother to support all versions and probably were done with it after 5.4 announcement.
Lua is definitely not underrated as an embedded Language. It is the uncontested winner of this field. If anything, I feel it is slightly overrated: it is easy to embed, but has no other real strength. Everything else feels about Lua feels a little bit meh for me. It is completely serviceable, and there are many apps where I have used Lua very effectively like Hammerspoon or Wezterm. But in the end of the day, every time I have to deal with a system that embeds Python or modern JavaScript, I am 2-5 more productive than I am with Lua. Sure, Python and JavaScript have their own warts, but they have grown and improved their ergonomics since the 90s. Lua, on the other hand, is a language that is philosophically hostile ergonomics.
Lua's philosophy, as far as I can get it, is to be minimalist and allows for emergent features. You want arrays? We don't natively support arrays, but you can use tables as arrays. You want classes? You can build your own class system or prototype system using tables. You want to implement anything else? Well, we've got some metaprogramming for you. The problem with this approach, is that you don't end up with one language, but with hundreds of different and confusing dialect, where each programmer does their own thing, this is how JavaScript used to be with regards to concurrency and classes, and it wasn't good.
The other issues that arise from this philosophy is that Lua lacks a lot of ergonomic features which cannot easily emerge out of its simple tables+closures+coroutines foundations. There are no type hints (like Python got), const (like JavaScript), default argument values, array/table destructuring, try/catch blocks, string interpolation, foreach loops, immutable values, etc.
These features sure add a lot of complexity to the language implementation, but they are extremely valuable in saving programmer time and cutting down bugs. Lua takes the Worse Is Better approach here and saves implementation complexity by pushing it down to the user. If this complexity doesn't exist in the Lua interpreter it doesn't disappear: the programmer has to deal with it by making bugs more likely and debugging harder.
Lua might be a worthwhile trade-off where the choice is between embedding Lua or Embedding nothing, since other languages are harder to embed. Or in industries where it's deeply established like gaming. But I cannot say it's a language I enjoy programming, and I don't see any reason to use it in a non-embedded context. Apparently no one else does, but that's not because Lua is underrated.
Your description of use-cases for Lua reminds me a lot of the use of Forth in the 80s and 90s.
Lua kinda has an unofficial type hint implementation (via lua-language-server). But at this point I would just use TypeScript.
> Lua's philosophy, as far as I can get it, is to be minimalist and allows for emergent features
IMO this philosophy only shines in languages with macro, e.g. lisp family.
You should take a look at Fennel ( https://fennel-lang.org/ ) then - it takes Lua in a lisp direction, including macro support.
I have several friends who have worked on embedded interpreters, and one has used lots of forth, the other lots of tcl.
WOnder how they compare?
Personally I would choose JavaScript over Lua anytime*. Lua gives me "poor man's JavaScript" vibe.
* (If the target hardware can afford V8/node runtime, obviously)
> * (If the target hardware can afford V8/node runtime, obviously)
If it doesn't, I'd still use Duktape or QuickJS over a Lua engine
What happened with the 5.4 announcement?
You eventually become unamazed by news like a new Lua version and lose interest. It was interesting and controversial in 5.0…5.2 period, but then code and userbases established and no one wants to break code or infuriate users. With all the half-subjective flaws, previous (alternate really) versions of Lua are absolutely “done” and usable, so just sticking with one is a readonable thing.
What products have you made with Lua?
Trading bots for Arqa Quik.
Mostly functional cross-platform animated ui toolkit based on cairo/pango/gdk. Never published, probably still have a repo. I was proud of it cause it was better than gtk (if you ignore gc-related stutters).
A backend for a boring accounting-related project.
I also have developed an active-record like platform using Lua, but dropped the idea eventually. It was a repl-devenv-like thing with “active” ui, data, transparent networking, etc.
In product-ish category that’s all probably. Not much of it were actual products, as in portfolio sense.