I studied at PUC-Rio and I met Roberto Ierusalimschy (the main author of Lua) when he was teaching a course on semantics. I once asked him if I could send a PR about a feature I wanted in the language and he said something that I never forgot: "Yes, but I won't use your code. I love that people send me ideas, but I actually enjoy coding... so I will gladly take your suggestions, though I will write it myself."<p>He then explained this "dictatorial" behavior is what allowed him to keep the implementation simple and concise over the years. At the time he boasted about the source code being less than 8K LOC, though it has likely increased in recent versions. (I think it was around version 3.) I'd recommend taking a look at the source code, it's truly a C masterpiece.
I've the feeling that Lua became popular mostly based on its implementation, fast, small and self-contained portable C code, and not for the merits of the language itself. Certain things are addressed in Lua 5.3, but in general Lua has several flaws:<p>- Before Lua 5.3 there was no integer type, this makes a lot of things harder than needed in programming, unless you just write high level code.<p>- Lua trivially departs from standard syntax like ==, !=, zero-based indexes, without good reasons, creating a general feeling of confusion.<p>- There was an odd idea about what to include by default and what was optional. The lack by default of bit operations makes the language always in need of a trivial library.<p>- Tables as a single data structure are not ideal for many tasks. Especially the dualism between tables that are indexed by sequential numbers and tables acting as maps. It's a lot more kind to your users to give up with the solely academical ideal of "just one data structure", and give programmers at least an ordered and a map data type, or at least come up with something better than that. Lisp attempt at doing most things with lists was much more successful and clean.<p>- The stack-based C API is not comfortable to use.<p>I could continue to be honest, for instance by default you can't type an expression in the REPL and see the value returned. However when the task at hand is to write small scripts for a larger system, the implementation of Lua offers big enough advantages to make it a worthy choice.
Lua is a big reason why I'm interested in both systems and PL today. I started using Lua to build game mods in high school, and I was struck by how simple it was compared with Java, or even Python that I had tried learning earlier. The all-encompassing "everything is a table" paradigm really sparked my interest in the design of systems of computation, and how a broad range of programing patterns could be expressed with a few primitives.
Stay away from Lua and use Python, Go, Node, Rust or even C in new projects. This is going to be a lengthy rant for a comment; apologies in advance.<p>Having written a ton of networking code in Lua I can tell it has a lot of design defects that most other programming languages have avoided. Especially the deeply embedded one-based indexing and lack of a separate integer type (chars are strings, ints are floats) make it wearing to type any code that has to parse any binary data. Even bit manipulation requires going through the FFI. Considering that Lua is often touted as the optimal lightweight solution in small embedded systems, these features are must-haves.<p>The builtin string pattern matching library attempts to mimic regular expressions, but bites the user in the leg every time they attempt to use it for anything remotely regex-y. Unfortunately most usual string manipulation seems to revolve around them and the string.gsub function.<p>The inconvenient string library is also largely irrelevant. The developers call their language eight-bit transparent which in reality means that the programmer needs a separate Unicode library, rendering the whole standard string library mostly useless. One cannot even format UTF-8 text, because the string library doesn't differentiate between characters and bytes.<p>The official documentation mostly revolves around C bindings. The actual Lua language documentation is provided by another web site that looks like it has been written by an attention-deficit child. Instead of getting to the point, the articles often first provide a list of ways on how not to implement things, or they are actually benchmarks of fifteen different ways to call the standard library to get the same effect. Sometimes, the provided code does not even work – for example, the given XML parser code crashes when it hits one of the error paths.<p>The small runtime and fast VM do not really matter when the language itself is lacking and requires a metric ton of external libraries to achieve even the simplest things that are possible in standard C and Rust, which provide the same level of performance and better type safety.
For those of you who are interested, I run a Lua newsletter.<p>The Lua community is small so every bit helps :)<p>Shameless Plug: <a href="https://Luadigest.immortalin.com" rel="nofollow">https://Luadigest.immortalin.com</a>
It's worth mentioning the debt Lua owes to Self and Newtonscript. An extraordinary amount of Lua's syntax and semantics is directly lifted from these languages. Newtonscript in particular seems to be a template for a great many of Lua's interesting features.<p>What drove me away from Lua is its philosophy of providing minimal tools in which it is <i>possible</i>, but never <i>easy</i> or <i>convenient</i>, to do work in various programming modalities. Polymorphism, namespaces and packages, arrays, unicode... these things all can be done, but require significant head-standing and in many cases a lot of boilerplate. Even proto-style OO, which you would imagine would be Lua's signature feature, involves lots of rigamarole compared to languages (like Newtonscript) where it is baked in and elegant.<p>I kept wanting Lua to pick a pony.<p>Throughout my usage of Lua, I've consistently gone back to Lisp, where I could change the language to <i>make</i> inconvenient things convenient when I needed to.
As a developer, I've always liked languages that stress maps/hashes/dictionaries/tables/associative-arrays as their man data structure.<p>Off topic, but I've always thought that JavaScript and JSON would have been a lot better without the relatively artificial distinction between objects and arrays. Now that there's object shorthand and destructuring, this will never happen, but it was a nice thought for a while.
To courious web nerds: currently both Nginx and HAproxy have got Lua scripting modules to extend themselves by implementing e.g. customized filtering, routing, caching, proxing, storage etc. One can even build a full featured web app backend in embedded Lua tied to Nginx.
Of particular note; LuaJIT can pretty much directly call C libraries. From here:<p>* <a href="http://luajit.org/ext_ffi.html" rel="nofollow">http://luajit.org/ext_ffi.html</a><p><pre><code> local ffi = require("ffi")
ffi.cdef[[
int printf(const char *fmt, ...);
]]
ffi.C.printf("Hello %s!", "world")
</code></pre>
So while, say, Python is "batteries included", LuaJIT is "all the batteries".<p>Using C libraries in regular Lua is fairly easy as well, but LuaJIT is exceptional.
Roberto Ierusalimschy, et al., on "The evolution of an extension language, a history of Lua (2001)" [1], is an interesting read.<p>The word "configuration" makes repeat performance in that paper, but oddly is entirely missing from this 2018 paper (by the same authors).<p>[1]: <a href="https://www.lua.org/history.html" rel="nofollow">https://www.lua.org/history.html</a>
While I'm <i>not</i> a developer nor I like lua I'm curious about a thing: what's the difference between for instance Guile scheme?<p>Because they seems closely similar to me and Guile is <i>far</i> more clear and effective, at least for my programming skills...
I'm planning to use tcc as a scripting language. Not sure if it's a good idea, but as long as I don't have to rebuild my code, and as long as it's not slow like most scripting languages, it sounds like it's good enough.<p>Although I agree it might be difficult to write scripts in C, in the end it might just depend on the core functions that are exposed.<p>I'm not a fan of C, I prefer python, but I guess I will have less issues when interfacing c code to c++. Python seems quite fat, slow, and too much different than C++.
What Lua lacks in terms of performance and broad-scale, low-level library integration can be made up for within the Rust ecosystem where these exist along with a well-built Lua wrapper, rLua.
I always perceived Lua of being completely weird, and asked myself why people would ever want to use it.
Especially nowadays, where embedded Python is everywhere.