Honestly Lua is one of those languages that seems decently nice to use, fairly performant, and just makes me wonder why it hasn't been adopted for use more broadly in domains beyond just like being embedded in game engines. Am I missing something?
It does not have any exciting or frequent releases. It is basically done as a language since 5.1. New versions can be safely ignored, especially when you want to use LuaJit.
These days people simply expect lots of churn and frequent releases to keep the hype for a language up.
Also the current trend it towards static type checking which is especially hard to implement for Lua. There are some solutions for gradual typing but there is not exactly first-class support for that.
The small standard library might also have been a problem in the past but these days I would argue that JS has normalized that part quite a bit.
I could use it for some light scripting, but definitely would not write whole projects in it.
You might be interested in Teal ("the typescript for Lua") https://github.com/teal-language/tl
https://github.com/teal-language/tl/blob/master/docs/tutoria...
You can send a PR!
We ran >200k lines of Lua for a 3d game at >60fps. We could not do allocations on the hotpath, or we would run out of our frame budget (which was around 1ms). Games are very hard to auto-test when not built with that in mind from the ground up, so any change to the code might unknowingly break any caller, and we would only know for sure once the game runs. Sadly the code base is 20 years old.
At some point (2.1?) LuaJIT added a peephole interpreter optimization which can follow a simple constructed table for awhile, and if it's never stored, the values it's conveying are just put on the stack.
I'm pretty fearless with creating transient tables, and run enough profiling to be moderately confident that the allocation sink is keeping that from providing memory pressure.
There's a larger thing here about the JIT being temperamental and having to kind of learn its moods, but: it's faster as an interpreter than other choices by a matter of multiples, and when the JIT works, it positively screams.
I once added vector4 as a primitive type in my fork of Lua (to avoid allocations altogether) - it was surprisingly easy to add, took me a weekend.
JS ate Lua's cake, not on pure technical merits (the two languages are very similar) but because of their respective environments.
[1]: https://en.wikipedia.org/wiki/Prototype-based_programming
It might not be in your particular awareness bubble. Parts of the infrastructure that transmitted the request that allowed you to post your comment (the most prominent one is Nginx, but routers and switches with Lua-scripting do exist).
In my case, I work in Kong (which has a very healthy Lua plugin), I edit my code with Neovim (Lua is its main plugin-writing language). So I kind of "live and breathe" Lua. Still I am aware of other pieces of software that embed it that I don't use (Redis, Wireshark, even Wikipedia supports Lua on its templates).
One interesting characteristic of the language is that it is "barebones". It doesn't have features that are "built-in" in other languages. Things like parsing a json file or making an http request. As a result, the "host program" needs to provide those. Which ends up making "flavor Lua" - Lua with certain assumptions about the host. In this way, Lua is not "one big continuous landmass", but instead an "archipelago". This lack of central point makes it impossible to attach a "marketing/hype machine" to it. It's more like a silent revolution, the language stands on its own merits, for better or worse.
Lua is the official language for writing Pandoc filters.
And, of course, NeoVim.
These are the contexts in which I use it; its embedding into TeX and Pandoc provides some powerful capability.
Given pandoc is written in haskell.. an interesting choice. I guess investing in a DSL syntax was a cost too far.
It was an average PL a decade ago and it is simply mediocre now. Only superb implementations like LuaJIT prop the language up.
I would prefer writing Enterprise Java (gasp) over writing Lua code for anything >5k lines. It's OK for small scripts but rapidly breaks down for anything larger. It's a bit funny that a complicated system PL like Rust is more comfortable to code than Lua.
Only using Lua personally nowadays due to Neovim and now that https://github.com/noib3/nvim-oxi has come out, I am going to use it even less.
What is magic in Lua nil? nil being false makes nil different from other non-boolean types, but it is both intuitive and convenient (I don't know a language where null/nil/undef are true in boolean context). What makes Lua a bit different from other script languages is that 0, "0", "", {} e. t. c. are not false in Lua. But it allows to avoid mess with truthy/falsy values we have in other script languages.
My solution, which was perhaps overly cute, was a table canonically named No, which is callable such that No(nil), No(false), and No(No) all return true.
So I could say
if No(value) then
In Ruby only nil and false are falsey, everything else is truthy.
I use functional programming extensively in Lua also. Could you elaborate on what it doesn't permit?
Integers were introduced in 5.3.
Assigning operators? It has metatables, you can absolutely implement your own operators.
If you want static typing you can use my IDE: https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis/
Granted, my IDE is incredibly opinionated and not for everyone.
Also, Lua is not my favourite language to use, doesn't even make top 3. However, the robustness of its design, considering its simplicity, is incredibly elegant.
I personally found functional programming non-ergonomic in Lua considering that anonymous functions are very verbose and there is no map/filter/etc in the standard language/library unlike just about every PL these days. You need to pull stuff in for basics and everyone does it slightly differently leading to non interoperability.
Sorry, I meant shorthand assignment operators. Those are quite convenient.
+=
Personally, I don't have a strong opinion on their omission, however I know some prefer the simplicity.
Woah, interesting ... provided there's success and uptake with this ... I'm imagining it could lead to a really slick and responsive editing experience that those of using (at least) slightly sluggish plugins might have been missing for a while now.
x = function(a,b) return a+b end
x(4,5)
Is that not a lambda?
"Luau (lowercase u, /ˈlu.aʊ/) is a fast, small, safe, gradually typed embeddable scripting language derived from Lua."
It has had 64 bit integers since 5.3 https://www.lua.org/manual/5.3/manual.html#2.1
filterdResult =
lambda(Table,
function(i)
if i ~= 42 then return i; end
end,
setToFilterOut = {}
function filterOutIfInSet(i, filterSet)
if not filterSet[i] then return i; end
end
etc..
)
Its similar simple to the javascript implementations, once functions are firstclass members.
Functional programming would be harder. You need alot of meta table, result hashing for that a + b hash(a) + hash(+) + hash(b) -> Resultlookup. So its doable, by the law of look it up yourself, it has been done.
OTOH, it is too close to C and not really a breakthrough language like Rust or Go. As far as style and brevity goes, Lua wins hands-down, but who cares?
But if you want something more "out there", it's also the main language used to program open-source radio control remote (openTX) for drones/planes/gliders: https://medium.com/rc-soaring-digest/ive-got-the-power-opent... https://github.com/jfrickmann/SoarOTX
2. Since it is embedded, it has a pretty small standard library that the embedder can remove or extend.
Both lead to Lua communities being more about individual projects which embed it.
Lua has very simple syntax and small stdlib which allows its implementation to be very small - you can add Lua to your application and not increase its size significantly. But when the size is not a concern most programmers prefer languages with rich, powerful syntax lots of features and batteries-included stdlib (which is completely opposite of Lua).
> And the arrays were exactly the same. It’s very funny that most people don’t realize that. There are good things about zero-based arrays as well as one-based arrays.
> The fact is that most popular languages today are zero-based because of C. They were kind of inspired by C. And the funny thing is that C doesn’t have indexing. So you can’t say that C indexes arrays from zero, because there is no indexing operation. C has pointer arithmetic, so zero in C is not an index, it’s an offset. And as an offset, it must be a zero — not because it has better mathematical properties or because it’s more natural, whatever.
> And all those languages that copied C, they do have indexes and don’t have pointer arithmetic. Java, JavaScript, etc., etc. — none of them have pointer arithmetic. So they just copied the zero, but it’s a completely different operation. They put zero for no reason at all — it’s like a cargo cult.