What I think about Lua after shipping a project with 60k lines of code

I think he was just offering the perspective of someone else that has also written a lot of Lua.

The fanaticism of Rust programmers...

Honestly the endless criticism of Rust "fanatics" is far more tedious than anything Rust developers say. Rust is a fantastic language. Do you expect people not to talk about it?

I read his post less as Rust fanaticism and more someone who has learned their first programming language isn't perfect - strong types? iterators? These are all things that are present in many languages, it just sounds like Lua is lacking them and he is discovering some of the cool features of other languages.

I think they are. Rust is a general purpose programming language, and Lua is a language specifically designed to be embeddable. But that means if you're making a project that embeds Lua, like Factorio for example, you have the choice of what language you write the code in. The choice is whether to write a function as native or to write it in Lua, and that choice might not be super clear unless someone else already made that choice for you.

This is completely different than assembly vs PHP. Assembly is a 'don't use it unless you have to' programming language, while PHP is a programming language designed for website building. You wouldn't use assembly to make a website because there are no frameworks for it and you'll scream and cry. You wouldn't use PHP to write the entrypoint to your operating system because PHP can't do that.

Rust and Lua are a lot closer together than PHP and assembly and it often would be reasonable to compare these languages for the same problems. It's not relevant at all to the blog post though because the engine they're using is built for Lua, and it's not really up to them unless they want to work against the engine and try to use a different language.

People complaining about Rust evangelism is about as much of a trope as the Rust evangelism.

Though I would rather spend my days listening to people talk about what they love rather than what they hate, so your response is more tiresome than the person you're replying to.

The great thing about toys is they are very easy to put down for a while and then pick back up again later with very little effort.

That matches my experience.

I've written programs in Haskell, and it was very satisfying. But going back to the project after 6 months of work in other languages was very hard. I took some time to remember the concepts, the abstractions and what the cryptic operators meant in their contexts. I've kept away of Rust for this reason: maintenance would be hard if I only dabble episodicly in Rust.

On the other side, my own experience with Lua was not very nice. I contributed (and patched for my needs) Koreader, an ebook reader with 180k lines of Lua. The lack of explicit types and data structures was a strong impediment. And the language has subtle traps... Everything is a table, but not all tables are equals: some tables are sequences (indexed by 1..n) with special operators (like # whose result is undetermined for other tables (which hurts like the famous Undefined Behavior of C++). With Lua, simple questions like "Is this table empty?" or "What is the size of a table?" are too hard for beginners.

So, complex artefacts are hard to go back after a long break, but many toys break easily when you come back after a pause, having forgotten how fragile they were.

I agree with this, but my point was that I cannot hide the details from myself, and will bring them up when they are relevant and confuse my poor friend just trying to learn Lua.

Definitely very little effort picking up my toy again after a 6 month break

As a long time C++ developer with only a few years in Rust, C++ is downright painful in comparison. However, I still cannot iterate in Rust as quickly as I can in Lua, unless the project is large and complex, then I'd argue that I can work faster in Rust. Languages like Python, Lua, Lisp really struggle in large projects because it becomes way too easy to break things unknowingly.

Iteration cycle of strongly typed languages can be very short too, if you pick the right technologies. Rust (and c++), unfortunately, has pretty long compile times compared to, say, Go.

The problem with loosely typed languages is that you don't find out until runtime that you have a problem. And if the problem is inside an if statement that users only hit 1% of the time, you might not find it at all except in the form of users very occasionally complaining that it sometimes crashes unexpectedly.

There are techniques in C++ that can prevent this situation somewhat but it comes at the expense of indirection (see pimpl).

IDEs are getting pretty good at refactoring these days. I do changes like that in Visual Studio and it has gotten remarkable good in the last few years.

I know that I would have found strong types constraining when I first started learning Lua in 2009, but do you ever really need to change the type of a variable after you create it? I did a lot of hacks using ternary true-false-nil and drive-by appending random state to a table it doesn't belong in, to be recalled later in some other random place in the code. The lack of rules makes even following your own ideas of structure easy to cheat and subvert.

I think your comment about opposite end of the spectrum has merit, because I find the strict rules to be refreshingly binding to my coding ideals. Rust is ergonomic to think in, and I have even used it to prototype things before implementing them in Lua.

To me, Rust vs Lua is changing a struct and then simply following the chain of compiler errors instead of trying to remember every last place a mushy table gets manipulated.

Lua isn't anything like SQL. "Table"s in Lua are like maps/dictionaries/hash tables, not relational tables.

It’s really much more like JavaScript (due to its prototypical nature), where “everything is an object” is effectively saying the same thing.

I really really don't want to do type annotations. I just want to know about:

  variable = 1
  print(varaible)

Last I checked I couldn't really find a good way to do that; but like I said: it's been a while.

That has been nice (at least for editing neovim configuration files). But what if I am editing anything else?

For example, I have then tried to edit Wezterm config files and there are no types. I did find some types someone made online but no idea how to instruct my editor/lsp where these types are or what they are for.

You can. In our game engine ~10 years ago we would hook the global table to stop designers from creating globals (the default in Lua without using the local keyword) at certain areas in the game frame, mostly to stop this exact trap.

I toyed with the idea of inverting the semantics of global and local in lua and to remove "local" and instead default to local and have a "global" keyword. Looking at lua.c quickly dissuaded me when I was a much more junior programmer, but now days it might be fun to try.

A linter like luacheck is better for accidental globals, but I think the GP was talking about doing a = someTable.typoedFieldName.

The default should be an error, since that's the only way to prevent issues where the wrong value gets passed around a lot before finally blowing up somewhere else (and good luck debugging that).

In cases where you really want to fetch the value or else get some default if it doesn't exist, there should be a way to do so that is distinct from regular dereferences and element access.

Eventually they got tired of me pitching for it and fired me.

I'm sorry but your anectode is simply not believable. No one gets fired for suggesting a harmless feature.

Did you try to justify in terms of reduced costs or increased sales?

I tried a similar approach with a team I was working with. We were building it on top of redis and after some basic benchmarks gave up the idea and figured out from the docs that that eval script is blocking.

Why wasn't Python used? I imagine for such a use case it wouldn't be that much heavier to use Python vs Lua.

Jonathan Blow criticizes the use of scripting languages in modern game development as outdated and inefficient, pointing out that they slow down performance, are error-prone, and complicate the development process with extensive engine integration needs. He notes that while initially appealing for allowing quick iterations and non-programmer accessibility, scripting languages often result in poor quality, bug-ridden code that requires significant oversight from professional programmers. Advocating for robust, compiled languages like C++, Blow dismisses scripting languages as a failed experiment and praises the shift towards more constrained and user-friendly visual scripting systems in platforms like Unreal and Unity.

(i don't mean to suggest that i agree with him, I just was curious)

I don't think so. He's shipped a few quality games. He can speak from experience.

That's not to say I agree with all his opinions.

How come? This doesn’t seem true to me, and your second clause reads like a non-sequitor

The analogy isn't very good, because the natural French language isn't a minefield full of undefined behavior.

In Linguistics, natural language, and native speaker intuition is the gold standard. The theory of the language is deemed to be wrong where it fails to capture it.

So right off the bat we know that a prescriptive institution like Académie française is on linguistic shaky ground; it is not aligned with science.

In computing, the specification is the gold standard, followed by documented, committed implementation behaviors.

haskell is great if you enjoy learning haskell. there's always a new build system, a complete redesign of how things are done, etc. i lost the plot around the time everything became an arrow (or was it a lens ?) myself, but I'm sure a few more generations of improvement have happened already!

Right now on Lua 5.4.2

I've had some success by tuning the GC with `collectgarbage('setpause', 100)` and then manually calling ` collectgarbage('step')`every once in a while.

That being said this problem isn't unique to Lua, There are horror stories about Unity and their integration of C# for example.

This is the goal of the Pallene project: https://github.com/pallene-lang/pallene

It isn't terribly hard to write the bridge code to lua, just monotonous to translate inputs and outputs from C++.

You throw a lua function into a table (usually tables are used as namespaces and globals are just a table) and then make that C++ translate to your normal one and handle the return value correctly.

The hard thing is building a system to pass in a C++ object in general as that required building a table for each instance that matches its class.

Good question. But essentially because things started out small and then grew from there.

Going forward being able to have seamless integration between the scripting and rest of the editor is a key differentiator and value added. For example being able to jump to the right API documentation relevant for the function call under the caret, or being able to open and jump to the game asset from the script.

I'm not sure how well a LSP type of integration would work here. As far as I can tell it'd need to evaluate the script in order to have best possible diagnostics and analysis and that won't work without the interpreter having the native game engine code available as well.

Of course my "solution" was mostly about slapping components other people built together.

  - Qt already has a text editor component with components for doing stuff such as syntax highlight quite easily.
  - I use tree sitter to extract symbol information from the Lua code.
  - I use an open source code formatter someone else built.

I also need elaboration on this. I presumed calling lua from c can be used to implement user-defined callbacks. Launching a thread for lua + locking seems even slower?

AFAIK metatables are still in Lua 5.4?

It's a joke wryly comparing its uncommon origins with its uncommon design.

There's no explanation.

https://en.m.wikipedia.org/wiki/Lua_(programming_language)#:....

It's unclear to me what you are trying to say here.

I agree, it reads as something posted by a chatbot tha glitched.

Res ipsa loquitur

Eh, I think I disagree with this. The point is that I can make very complicated libraries in Teal, and those compile down and are usable in lua scripts. This is where I actually used it - very simple scripts, very large and complicated library imported into those scripts. If you really need to prototype, just use lua, not teal. I've never found prototyping in teal to be a problem though.

On the other hand, I absolutely despise type annotations as comments. There is something so unclean about that - if I want a readable library, I want there to be type proofing all the way down. No switching between static and dynamic.

It’s kind of common to use the TypeScript compiler purely as a linter these days even in a TypeScript-only codebase. You actually want to use a faster transpiler anyway, and when you do, there’s no technical reason not to run the code or the test suite while you still figure out the types. In fact, I’m becoming convinced that this kind of setup (and way of working) is actually the best of both worlds.

Nope, you can embed it. Teal is written in teal, and compiles down to lua - so you can simply put teal as a lua dependency. I used it with gopher-lua (Golang lua environment). https://github.com/teal-language/tl/pull/523

makes me think that they haven't used python in a production environment. It's a mess, pip, poetry, stupid eggs.... that's just deployments then there's personal dev environments.

Since everything has to be relative from the current directory, it's not very convenient to move files around or make a contained module that depend on its own module.

What? Not in my experience. For instance, I have lpeg install ~/.luarocks/lib/lua/5.4 and LuaXML in /usr/local/share/lua/5.4 (just to name two modules I use). To use them, it's just

    local lpeg = require "lpeg"
    local xml  = require "LuaXml"

And I avoid such code. Not everything has to be OO.

Lua can also be massively faster than Python (LuaJIT).

I have been having thoughts, wild and incoherent, about the evolution of a given programming language. What does it take to survive and thrive? I might describe my programming career as being kind of a refugee: on the web, I moved from plain .asp to Perl, fled Perl for Python ...

At the start, a language needs the ability to evolve. I recall reading a book on Python before I adopted it, a book which was so off-putting that I ended up delaying my attempts to use Python, and it went on about Python's philosophy when it came to division. I knew that, at some point, Python would have to change away from integer division by default. And it eventually did. It was a mistake because it was non-obvious, and the language changed to fix it. Good.

Now, though, all kinds of things have crept into Python which are decidedly non-Pythonic: the walrus operator, which looks like something that escaped from a Perl dungeon; the docopt module, which has a weird trap of it being a module you must know about, but only if someone has decided to use it; the utter shambles which is the whole environment and library packaging "let entirely too many ways to do it exist;" or the community's preference for Requests while it somehow has yet to be co-opted into the standard library. I am sure I have gored someone's ox here.

Perhaps a language needs a certain window before it is finally frozen in place. Or a more stringent, forceful mandate than the Zen of Python, which I think has been Not Enough. In a way, I am reminded of the Agile Manifesto, which was well-intentioned but had no enforcement, no orthodoxy; it lacked teeth to nip at the heels of those who fail, who go astray. Originally, I had considered that the Network Effect as a way to freeze things, but it seems to only work on protocols and less so on languages.

Yeah that would've been lua2.1 described here: https://www.lua.org/spe.html

That was a surprising downvote.

I was referring to this:

"it is customary in Lua to start arrays with index 1" [1]

Not being a native English speaker, I may have phrased something wrong. I find "one-based indexing" in arrays not particular intuitive, and error-prone.

Better?

[1] https://www.lua.org/pil/11.1.html

Can you quantify this and link to the implementation?

In other words, you don't like Lua, because your favorite IDE doesn't properly support it?

That's normal. Many - perhaps most - programmers lack appropriate mental tools to compare languages meaningfully. They instead use any kind of heuristic they find useful at the time. The never-ending discussions that mistake familiarity with readability are another example of this mechanism.