I had to maintain a very large Lua codebase that has been active for several years. One big problem with Lua was how it will happily take more or less parameters to functions and continue to execute compared to something like Python where it is an error to pass the wrong parameters. This meant when we update a function signature we would often incorrectly update call sites, etc.

I can't remember the specifics but we had a few issues with tables being both dictionaries and lists. IIRC, if you delete a list index and there are later list indices, they will turn into dictionary keys. We had a few bugs to do with not traversing the entire array portion of a Lua table because of this.

I also implemented a few classic algorithms, e.g. bisect in Lua and you have to be very careful with 1-based indices. You also have to be very careful when interfacing between C and Lua. I prefer 0-based indices and [start, stop) style ranges for everything nowadays.

I much prefer statically typed code during maintenance. But dynamically typed languages like Python or Typescript where you can bolt on types, later if you wish, are not too bad.

Also using named parameters as much as possible is great for maintenance.

I have, roughly, sworn off dynamic languages at this point. Although I have dreams of implementing a firm typed system over Common Lisp.

(I know Python type checks aren’t mandatory, but for this question assume that the type checker is running in CI)

  https://coalton-lang.github.io/20211010-introducing-coalton/

?

Isn't that exactly what unit tests are for?

I personally believe it's a valid argument (others will disagree). IMO the main benefit of static types isn't for correctness (nor performance) - it's to force programmers to write a minimal level of documentation, and to support IDE features such as autocomplete and red underlines. Hence the popularity of Python type hints and TypeScript, which provide these features but don't fully prove correctness nor provide any performance benefit.

I understand that statically typed code doesn't mean bug-less code, but I always find it odd that dynamic language enthusiasts feel like they need to stretch the benefits. Dynamic languages are great for many things. Strictness is not one of them and that's fine.

The same thing happened with our huge legacy PHP monolith, which was written before type hints were a thing. Developers were reluctant to refactor large chunks of code when the time came, because it was just too easy to introduce bugs - you couldn’t be confident about anything without manually digging through tons of code. So, when business requirements changed, they’d just bolt on some hacks to avoid touching the existing, tested code, and call it a day. It became a self-reinforcing loop: fear of refactoring → more hacks to avoid refactoring → more brittle code → even more fear of refactoring. Eventually, they added type hints and a linter to analyze them, but by that point you start to wonder - why are we even using a dynamic language and fighting its quirks?

True for any language really. There's an entire category of blog posts: "I used language X for 2 weeks and here's my hot take". Okay, great. But what do you really know? For every language I've used for a serious amount of time I've changed opinion over time. Some things that seemed like neat ideas at the start turned out to be not so neat ideas down the line. Or things I considered pointless or even stupid at the start turned out to be very useful once I better understood the nuances and/or got used to working with it.

And of course it's double hard to judge will come back to haunt you a year down the line.

Even as an experienced programmer I find it hard to properly judge any of that from just a few weeks.

The language, is beautiful.

It really could use a fully statically typed layer that compiles down to Lua, and also fixes some of the stupid stuff such as 1 based indexing and lack of increment ops etc.

That's Teal: https://github.com/teal-language/tl

One of the things I suspect your team is doing wrong is you are using the PUC Lua C API instead of the LuaJIT FFI. That is one of those things which just completely destroys the "happy path". The PUC Lua C api is effectively a deprecated feature at this point. A few years ago you could have made the argument that the PUC Lua C API is more portable than LuaJIT which is absolutely true. But q66's (from Chimera Linux fame) cffi-lua project nullifies that argument since you can now use the luajit-style FFI in PUC Lua, which works on every platform that libffi supports.

Again I understand your frustrations with the language since you are working within a fundamentally adversarial environment. Perverse incentives can easily destroy any good patterns you can establish since the language is so flexible. I implore you to explore the language outside of your day job.

Except for the indexing mismatch, I've found calling Lua from C and vise-verse very easy.

You likely mean JavaScript. Typescript is very much statically typed, unless you allow everything to be `any` and `unknown`.

Typescript is mentioned in TFA as a desired (but not available) option, because of the great static typechecking support.

A TS compiler will reject an ill-typed program. You of course can just strip the type syntax and get a valid (though buggy) JavaScript code.

Ehh, not exactly. Most C++ compilers won't output machine code for inputs they don't understand. Though of course, you could simply translate some C++ code yourself into machine code and then say C++ is just like TypeScript in that way. "If you turn C++ into machine code, the machine code lacks types!" "If you turn TypeScript into JavaScript, the JavaScript lacks types!" The main difference is the C++ compiler won't generate machine code for you if the code you provided it doesn't compile, but the TypeScript compiler essentially treats types as a lint (unless extended by compiler plugins such as `typescript-is`, which I greatly enjoyed back in the day).

Also, CHERI begs to differ. And even other than that, machine code isn't dynamically typed because it's not typed at all. Usually, everything is data (usually even the machine code itself, except on Harvard architectures), aside from any architecture-specific memory protections (and other protections), if applicable. I could probably go on about this for days.

> A TS compiler will reject an ill-typed program. You of course can just strip the type syntax and get a valid (though buggy) JavaScript code.

Can't Deno execute TypeScript directly? Last I checked, it didn't do typechecking itself because [the size and complexity of tsc].

For what that's worth, cling also exists, so try tricking that into executing compiler errors. I don't think it would.

Sorry, I think you've been swindled.

The Typescript compiler is made by Miscrosoft and is called tsc. It very much heeds the type annotations, and very much rejects ill-typed programs. An LSP based on it does the same in an editor. Also tsc supports refinement types via flow control analysis and a bunch of other static correctness checks.

Deno, bun, swc are not true compilers like tsc, they don't do much correctness checking at all. They discard al the type info, and then operate on pure JS (modules conversion, minification, etc).

No it doesn't. Even on the strictest settings, Typescript is unsound in trivial ways, which I hit every time I use it in anger (e.g. undefined in unassigned variables). And Microsoft libraries seem perfectly ok with asserting their type errors away without any validation, specially for JSON values.

I had a similar experience with Python until I found Pydantic.

I haven't had a chance to try Elixir's new type system (is it ready yet?), but at least their strong-arrow model would ensure that runtime checks for dynamically-typed values are done eventually.

If you need bulletproof soundness and JS as the runtime, you have Purescript %)

Which ways you say? That I know of: Both TS and C# can carry hidden nulls; both made the mistake of covariant arrays, but C# actually type checks accesses; and any other unsound case I know of in C# involves a runtime type check as well.

No matter what language you’re in, the second you use a cast, you’re asserting to the compiler that you know more than it.

But I bet on swc, which is used by Deno internally, or on the Bun's built-in transpiler that does things similar to swc or ts-blank: they all assume that the code is semantically correct (not just syntactically valid) Typescript, and then just ignore the Typescript-specific bits.

Well, we have bytes, words, doublewords and quadwords on the machine level. They are usually referred to as data types in the processor manuals.

Being surprised by aliasing would have happened the same way in many languages, but not everything but C. It can happen in C too! But maybe in Python you would have used an (x, y) tuple and gotten an error from trying to mutate it, and certainly in Haskell or OCaml you wouldn't introduce mutability implicitly. In Tcl there's no way to get that problem in a list of lists, and in languages like Golang or Rust or C# you'd probably use an array of structs which would also be immune to aliasing. You could have the same problem, but it's less likely. I've known experienced programmers who were surprised by aliasing bugs, and even had trouble debugging them, maybe because they spent a lot of time in languages where they were possible but less likely.

What do you mean about ignorance of type annotations?

Defold is a great engine. It has a somewhat steep learning curve (steeper than you'd expect, anyway) and its fair share of quirks, but more often than not the quirks are deliberate tradeoffs that steer you in the direction of structuring your game well. It really feels like an extension of the lua philosophy of giving you a narrow set slightly odd, but very robust and flexible tools that you build everything else out of.

I'm back to using LOVE2D for general tinkering but a few months with Defold really changed how I approach things. I've been meaning to write up a post about it. Either way though, I'd highly recommend checking out Defold to anyone interested.

Surprisingly, LuaJIT is not mentioned even once. Luau is mentioned, Teal is mentioned, Fennel, not. (But Haskell is mentioned!)

Little is told about the general code structure, likely because it's dictated by the (C++-based) game engine with Lua bindings. It would be interesting to see an analysis of a comparably large game built with Löve, for instance.

Viewing a list of folders? Lua. Viewing a list of messages? lua. Viewing a single message? Lua. Those were the three main modes and UI options.

All the keybindings, layout, colour setup, and similar was dynamic. It actually worked out really well. For comparison I just ran "wc -l" against he codebase: 60k lines. Combination of C++ and Lua, but mostly Lua.

Having good scope and good tests made such a thing fine to support. Mostly the pain was broken MIME messages and handling dealing with the external world - e.g. invoking gpg to handle decryption and encryption.

I'd work with big-lua again if I had the need, it's a fun language and very flexible.

It is possible to make it not crumble under its own weight, right? I had my share of Lua nightmare with more than 100K lines of code back when I was a gamedev [1], and it seems that there are some requirements in order to remain sane with the growth. Thankfully there are now multiple working type checkers for Lua, unlike when I had to built my own.

[1] https://news.ycombinator.com/item?id=18351788 is my canonical answer, but I have written many other comments about Lua which should be easy to search.

The main reason I like static languages and other such things is that after many decades of the programming community developing, since before I was born, we have not found very many best ways of "bringing enough discipline" to a codebase. It really all amounts to the same disciplines over and over. Check the types. Be sure guarantees are maintained. Document the input and output parameters. If there were dozens of very distinct and mutually-contradictory ways to impose this discipline, and there was no clear domination among those ways, then it might make sense for all of our languages to be loosey-goosey and not impose anything directly. But since we all generally find the same disciplines, we might as well pull those up to the language level and thereby enable them to be fully supported, and share the tooling among each other rather than expecting every junior dev to reinvent it from scratch... which they won't.

Defold uses LuaJIT (except for web which I think uses Lua 5.1 compiled to wasm?), so it's taken for granted.

My initial point was just that it's kind of nice to have something that's usable from the get-go. I don't miss my gigantic neovim config one bit.

> ...why Lua was designed this way. Dmitry told me that Lua was created at the Pontifical Catholic University of Rio de Janeiro and that it was acceptable for Pontifical Catholic Universities to design programming languages this way.

The PUC in Santiago de Chile is even better, academically, and has some 34000 students at any given time.

It would be very surprising if different languages originating from these universities had significant design features in common!

But if your engine is already doing the heavy lifting, a slow scripting language will not matter, because it's not doing much.

Also gdscript is pretty nice to use, even if it's lacking tuples, unpacking and other things.

Other games with Lua scripting: Roblox, Baldur's Gate, Civilization VI, Crysis, Factorio, World of Warcraft, Far Cry, Leadwerks, Friday Night Funkin', Foldit, Garry's Mod, Aquaria, Balanced Annihilation, Bitfighter, Bos Wars, Cataclysm, CivCity: Rome, Civilization: Beyond Earth, Company of Heroes, Cortex Command, Counter-Strike 2D, Crimson Steam Pirates, Dota 2, Dungeon Crawl: Stone Soup, Dungeons, Dungeons II, Dungeons III, Elven Legacy, Empire: Total War, Escape from Monkey Island, Eufloria, Exodus from the Earth, Angry Birds.

Lua is traditionally the scripting language of choice for game development. It was absolutely ubiquitous in the industry before the days of Unreal/Unity. Famously, all of the WoW UI was Lua.

https://www.inf.puc-rio.br/~roberto/talks/curryon2017.pdf

Oddly enough, I learned that they used Lua by reading the license information which came with the game. I don't remember if it was on the back of the box or in an paper insert, but it surprised me to see it included for some reason.

Recently had some time to spare and moved to Fennel. It has some sharp edges but in the end I find it much easier to maintain. In fact, I think it’s good enough to replace any kind of Lua for me.

> O.C.: Have you consulted about this “tables” approach with other Lua developers?

> I.T.: After that, I went back to Dmitry and asked him if my understanding of “everything is a table” was correct and, if so, why Lua was designed this way. Dmitry told me that Lua was created at the Pontifical Catholic University of Rio de Janeiro and that it was acceptable for Pontifical Catholic Universities to design programming languages this way.

Graphical-only instructions were maddening, though! Especially organizing ideas by dragging them around in 2d space. I would have loved the ability to drop into written code.

Have you studied Software Engineering? They discuss LOC in depth and many academic papers on KLOC are in SE literature.

If you wrote a program that is 1,000,000 lines of code you could also write a blog post about your thoughts on "writing 1,000,000 lines of code".

You could also write a program that is 200 lines long and write a blog post about "writing 200 lines of code".

One is not better than the others, you are just informing your audience of the topic under discussion.

I think most conversations around LOC assume that it's not an idiot writing it, and I think in general, this is a good assumption to use when it comes to code discussions.