A History of Lua (2001)
lua.org
lua.org
Almost every single time, without failure.
I consider its simplicity and the fact that people merely complain about its syntax as highlights of an extremely thoughtful piece of software.
I have complaints about its use for threaded work as well as performance, but it’s relatively hard to run into issues with the language in regular practice.
I don’t buy the lack of types argument in any programming language to be a compelling argument. Maybe consider that you or other authors you’re working with are bad at writing software. It’s a more boring conclusion and more often more accurate.
I don't buy the lack of seatbelts argument in any car to be a compelling argument. Maybe consider that you or other drivers you're driving nearby are bad at driving.
For me, using types in Swift is sort of like “NOS” in that it’s helped me go faster (and further”!
In python, go and C maybe, but in typescript? People tend to kungfu-type their APIs way too much where healthy repetition would suffice.
I believe ts typing power will eventually become “considered harmful”. I also think that ts should have a way to intertwine types as it does now, but leave that to technical part of dts and give a way to declare that by <that gibberish> you meant <this clear interface>.
Remind me a bit of Rust's type system.
Types are a good idea of many languages, but not a universally good idea.
I love your seatbelt analogy. Since seabelts are a good feature of cars, this does not mean at all that they would be a good feature for sailboats. Or for bicycles. In fact, they would be a terrible and very dangerous feature!
And if you happen to want lifejackets and seatbelts on your bicycle, then everybody will be safe to assume that you are an exceptionally bad rider.
Same thing for wanting types on languages where they are not needed.
This is why lua is in beginner sandboxes like robblox, which then will later turn into jaded developers, yearning for types.
Types can certainly help prevent something from going wrong, but they're not a zero programmer time cost safety feature.
OP worded it aggressively, but if someone can't see how others benefit from lower overhead, they should look closer.
Maybe I'm just missing something. If I recall, I was simply trying to create a new 'object' (game character) from a template but it required metatable boiler plate that just made no sense to me.
Many languages, this is simply a = b, or at most allocating some space first.
https://github.com/mikelovesrobots/lua-enumerable/blob/maste...
See: table.dup()
Lots of people obviously have a problem with this as it deeply different from the algebra derived assignment syntax.
local a = b creates a local copy, but even then, its not a deepcopy, containing references to other tables.
Lua's designers have a sort of maxim "if it can't be done perfectly, let the user roll their own". This can be frustrating, but for table-copying it's not surprising. Do you copy subtables by reference or value? What about recursive tables? Mutually recursive subtables? Closures in tables? And then userdata can contain references that are opaque to the language runtime. It's not easy to define the behavior of deep copy in the fully general case.
OK, I've considered it. Now what?
(I don't use typed programming languages, I just want to call out this kind of rhetoric.)
Completely happy to accept that I'm a horrible developer. But that doesn't really solve any of my issues.
(I have absolutely no issues with Lua btw)
Hence the reason cloning is a library function rather than core: when you have only one data structure, there are a lot of ways to copy it, and that's before getting into the various ways that metamethods can override the default behaviors of a table. Do you want to clone every pair in the table, or do you want to clone only the ones returned by `pairs`, which has a metamethod which can override the default behavior?
There are a dozen decisions like this to make.
You are making the classic mistake of thinking you aren't also just as bad as everyone else. Chances are you are just as bad or worse.
Taking advantage of tools that make mistakes less likely and accepting that you suck just as much as everyone else are requirements for being good at writing software I think (this applies to anything really).
Both languages strongly appealed to me, probably because of their cohesive (one-man!) designs, although I never got the chance to use them professionally. So I do agree that a strong, usually one-person, design is the way to go. But both Algol 68 and Ada failed for other reasons. I'm speculating, but I suspect they simply required too much of the average programmer: mathematical sophistication in the case of Algol 68, and discipline in the case of Ada.
The other plank of TFA's argument is that successful languages are built up slowly based on experience of requirements. I think if such a language ends up any good, it's either luck or someone spending a lot of effort pushing back on bad proposals. I'm sure you too have a list of languages in mind which grew in an undisciplined manner, until they strangled themselves. I think of language designers who allow that as like Maxwell Smart in Control headquarters, running coloured strands of wool between pushpins on a map until it's a woolly mess.
I suspect what really made Lua a success is it found users among game developers at the right time in its development, and did not try to be much more than that. In that sense, by listening to users and adding things, they achieved a good design (I assume – I don't really know the language), and because it did not achieve wild success that constituency of users was not so diverse as to baroquify the language.
A language can fail if it is a clean design but doesn't have users (Eiffel). A language with an ugly, committee, design can succeed if it has users (C++).
I think Lua would feel much better if it stopped at 5.2 (or even at 5.1, fixing the shortcomings in 5.1 way) and took care of what’s called ecosystem, emerging around its game popularity.
What is the feature you're referring to here? If I read it correctly, it sounds more like JavaScript with their competing module/import schemes.
I've found using hererocks[1] makes setting up lua and luarocks on Windows very easy. Running it in visual studio's command prompt has let me install pure Lua and C rocks.
However, I've noticed many rocks aren't updated on luarocks and the best way to install them is to point luarocks to the rockspec file in their git repo. Instead of `luarocks install testy` you do something like `luarocks install https://raw.githubusercontent.com/siffiejoe/lua-testy/master...` I don't use Lua for desktop development, so I only use rocks for dev tools to help write Lua for my embedded target, so I'm not sure how popular luarocks is these days.
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
I could use it for some light scripting, but definitely would not write whole projects in it.
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.
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.
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!
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.
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.
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.
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.
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.
It has had 64 bit integers since 5.3 https://www.lua.org/manual/5.3/manual.html#2.1
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.
+=
Personally, I don't have a strong opinion on their omission, however I know some prefer the simplicity.
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.
x = function(a,b) return a+b end
x(4,5)
Is that not a lambda?
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.
"Luau (lowercase u, /ˈlu.aʊ/) is a fast, small, safe, gradually typed embeddable scripting language derived from Lua."
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.
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.
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.
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.
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
Lua is also my go to suggestion whenever threads about which language to use for configuration come up. The syntax of lua tables are basically JSON, except without quoting keys and with comments. And the overhead of embedding it is likely close to nil compared to the interpreter for YAML or whatever.
It's a nice language. Wish I had something more profound and complex to say about it. I would just suggest considering JuaJIT if you ever do need to work with C and it's allowed. Or just Lua if you're a masochist and want to deal with the stack.
Honestly, I keep finding LuaJIT's FFI to be profoundly disappointing. It falls into the common FFI trap of support, essentially, a C ABI—sure, it parses C declarations, but without preprocessor support and no good way to ask for, say, "just get me all the declarations from errno.h", it cannot work with the universe of code that expects you to pass in e.g. symbolic constants provided in a C header, or preallocated structs, or via preprocessor macros, that maintains compatibility only at the C source level.
It's not an easy problem, to be sure, short of doing the C++ thing and embedding most of C outright.
I wound up writing a thing for this years ago that worked pretty well for the use cases I had at the time, but it was pretty complicated (implementation wise) and had some potential conflicts with other FFI-written stuff that imported "almost but not quite correct" stdlib definitions - since my thing would always import the exact definitions from the system header files.
Still, it was fun and I thought it worked reasonably well for what it was.
I have been prototyping with it the past couple of weeks, and it took just an hour to wrap all of the glm matrix and vector types, including overloaded operators to do fully transparent vector and matrix algebra in Lua, including passing of values to and from the outside world. I was really impressed by how straightforward and simple it was.
Love the language!
In the first week or so, I was a bit weirded out by the lack of language features, as I come from C#/Typescript/C++, but I was very surprised that after 2 or 3 weeks, I was already doing very complex tasks on the code base.
I think a lot of that comes from the simplicity of the language. It's very difficult to surprise you, everything works in pretty much the same way.
Here are some things that I will miss once I move to other languages: (note that most of these are not things that come from simply using lua, you have to implement it into your framework/engine, but they are still pretty common)
- stack traces print the contents of the variables in the stack. Not all lua code bases have this, but it is easy to implement.
- if the code crashes, you can fix the code and continue. This doesn't always work, and requires the code base to be written in a way that supports it, but it is definitely possible and I've used it many times.
- debugging works really well. You can easily attach and inject code, stop on exception and inspect the state.
- settings are also lua code. This is probably the biggest thing I'll miss. I love being able to have simple functions as part of settings (e.g. things like tweening functions), being able to generate settings based on other settings, or run simple sanity checks, all on the same file.
- index starting on 1, this is definitely an unpopular opinion, but IMO it just makes things so much easier. When you need to access the last element, you just do tbl[tbl_length], no need to decrease by 1, or doing a for loop, you only specify the indices you're actually accessing "for i = 1, last_index do end". I think it really helps with off by 1 errors. I used "normal" indices for over 10 years before this project, and I would still occasionally have these errors, but with lua, I don't really remember having them.
- not having to fight the compiler to quickly try out different things. Need something from a completely different system? Just add it to the global table and access it from the other place.
A big learning I got from transitioning from languages with a very strong type system to a dynamic language like lua, is that in order to be effective, you really need to use code architecture patterns, otherwise things become very hard to reason with. This might be counter intuitive, but I think you need to be a better programmer to use lua effectively, than you need to with a language like C# or Typescript. With the latter languages, the compiler helps you a lot, but with lua, you have to know how to use these things on your own, because you can pretty much do anything and that can be reeeeally bad :)
Interesting; how do you manage to keep consistency? Do you have special tools to e.g. detect inadvertent global variables? I once wrote a Smalltalk VM in Lua (https://github.com/rochus-keller/Smalltalk/blob/master/Inter...) which is a much smaller code base, but even with this modest size I quickly would have lost track of e.g. scopes and names without tools I had to write myself (https://github.com/rochus-keller/LJTools).
Although, I've been using luacheck https://github.com/mpeterv/luacheck. It is quite nice, but you have to write down the global variables by hand on the config file.
Edit: Also, the vscode lua plugins have been getting quite good, and completion works to a certain extent.
-- luacheck: globals init handler
-- luacheck: ignore 611
[1] https://github.com/spc476/port70/blob/master/port70/handlers...
Funny enough, I was just mentioning to a friend this weekend that I would love to write Lua as a full time job (and particularly in gaming), but those jobs seem nearly non-existent.
How do you recommend going about finding opportunities like yours?
As for non "AAA", I think https://love2d.org/ is quite popular for game jams and commercial 2d games - I haven't used myself though.
So maybe look for opportunities in companies using those engines.
I find this sentiment interesting. Perhaps somewhat akin to Linus Torvalds famously preferring C to weed out bad programmers.
I think many people would say that a language which makes it easier to do things poorly is objectively worse than the alternative. But the way a language "selects" the sort of programmers that use it is an important second-order effect (maybe even more important than the initial one?).
Not modulo!
We initially began with Python for some of these things, which quickly became an untenable and elaborately consummated performance disaster. There are plenty of techniques to get around its slow start-up and performance issues, but they come with a slew of new complications compared to the simplicity and ability to quickly deploy/update/execute from local file system.
Lua for us makes the difference of being able to, on one and the same piece of hardware, manage a thousand simultaneous phone calls instead of just a few hundred.