With dynamically typed languages I feel it's better to wait until you've tried to maintain the code for a while before you consider the languages effectiveness.
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 saw someone describe python as “stressful” for this reason and I couldn’t agree more. It’s difficult to have confidence in any change I make or review. I need to sit down and manually exercise codepaths because I don’t get the guarantees I crave from the language or tooling. While with the small amount of Rust code I’ve written lately I could yolo changes into production with no stress.
Agreed. I had to work in a larger Python codebase after spending a few years with Go and Rust and the drop in logical confidence around the language was remarkable.
I have, roughly, sworn off dynamic languages at this point. Although I have dreams of implementing a firm typed system over Common Lisp.
Same, though my trauma was Ruby. Those Rubyists who were apparently born with the language spec in their heads can do amazing things, but I am a mere mortal who needs to be told I wrote bad code right when I wrote it, not told at 2am on a production server.
In a large enough code base, there is no "your code". There is the code you wrote today, there is the code you wrote two years ago, there's all the code people are writing around you.
I change a function's arguments, I'm _pretty_ sure I caught every place it's called (spoiler alert: I didn't, because someone calls functions dynamically based on their names with call_user_func_array, maybe), and I ran the test suite - everything works, and I've fixed what doesn't.
Except some of that old code written 8 years ago didn't have good tests, or didn't have any tests at all, or didn't cover the specific code path.
And now it's 2am on the production server.
Now, you could tell me - Pavel, you're an engineer, you should be sufficiently dedicated to your craft to verify that the tests are testing those paths, you should find all those instances where that function is called (a few dozen times across the codebase), and check that those tests exist and are good. And you're not wrong! I should be doing cleanup in the codebase as I go, washing those dishes while I wait for pasta to boil or whatever...
... but now I've given myself two more actual engineer-weeks of work for a change that just needed to add a flag to a function to make sure only premium users get emails when something happens. My manager will be thrilled to hear it. Do you think I'll get a raise?
I’m assuming that Python code base didn’t have thorough type hints. What if it had? Would Go still feel safer? I know these aren’t checked in runtime, but Python type system seems more thorough than Go’s, so shouldn’t a Python code base fully typed be even safer than Go? If so, why not?
(I know Python type checks aren’t mandatory, but for this question assume that the type checker is running in CI)
Since Python type checking is functionally optional, it implies that somewhere, somehow, someone has opted out, or has used a type checker that differs subtly but unpleasantly from the one you're using. Python's type checker systems are fundamentally a _linter_ more than something like Java or C...or Rust.
It's not about feeling. It's about the theorems you can make about the codebase. With Python the answer actually is ¯\_(ツ)_/¯.
You're hand-waving the insane amount of effort that would be required to type every bit of Python code that gets executed. You get that by default in statically typed languages.
Even then, you're reliant on the correctness of a 3rd party tool vs a 1st party compiler. It's never going to be as good of an experience.
Yes, but in practice, is the difference significant enough to matter? I’m genuinely looking to see if I’m missing anything when favoring Python type system over Go’s.
One difference is that Python's type system is unsound. You can write code that passes `mypy --strict` but still contains functions that, for example, claim to return an `int` but actually return a `list` [0]. AFAIK it's not possible to circumvent Go's type system in such a way.
The biggest limitation of Go's static type system vs. Python's type hints system that I can think of would be the lack of union types, with nullability a close second (and it's just a specialized application of union types in Python). An interface in Go can be anything under the hood, though you at least know that, whatever its concrete type, it does implement the methods exactly as defined.
You can definitely circumvent Go's type system with unsafe operations (with FFI also recognized as inherently unsafe) but that's a clear boundary that you know you're crossing (albeit not quite as clear as e.g. in Rust).
Yeah, that's a common argument for dynamic typing. You're writing tests anyway (right?), and those will catch type errors and many other kinds of error. Why bother with a separate level of checking just for type errors?
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.
Except now you're writing and maintaining twice the amount of code instead of relying on the compiler and/or type checker to help you catch those errors
Sorry, but I don't agree that static typing is a replacement for unit tests. I can see static languages having fewer unit tests, but it's not going to eliminate them.
Static typing is a replacement for unit tests aimed to catch type bugs. Also, no one has 100% code coverage so might as we get some guarantees for granted.
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.
Sure, but only some of the unit tests are about values. Others, at least in my experience, are any handing various aspects of the implied types of values, and those can largely be removed.
Moreover, a good type system can also force the values to be right by enforcing certain invariants directly in the type system. For example, let's say I have a function `deleteProjectAs(user, project)` that deletes a project, but it only works if the user is an admin, otherwise it throws an error. I can write a bunch of tests that validate that this function checks that the user is an admin in all sorts of different cases, but with a type system I can write something like `deleteProjectAsUser(user: Admin, project: Project)`, and this guarantees at the type level that no non-Admin user can delete a project.
The point here is not that types can replace all tests, but that well-designed types can get rid of a lot of them.
You're tearing down a straw man. Your parent poster did not say it eliminates tests. He said static typing mean less tests. He didn't say static typing is a replacement for tests either.
One of the big advantages of Rust's type system is that, if you decide you want to change something (add a parameter, give a type a lifetime, rewrite an entire module), you can just do that, and then follow the errors until they're all gone. Often, once the types have been fixed again, the result will work first time when you try and run it.
In this regard, Rust (and other languages where lots of data invariants can be encoded in the type system) is very flexible and easy to maintain indeed, because you can easily make changes, even in very old or poorly-maintained code, without having to worry about the consequences. Moreover, rather than writing all the unit tests yourself, it's as if the compiler is writing the unit tests for you.
In fairness, you can't encode everything in the type system, so you still need unit tests in top of that, but in my experience you can get away with far fewer. In general, I would say that Rust's type system, when combined with unit tests, is far more flexible, powerful, and easy to maintain than dynamic Python with only unit tests.
Your 2-3 points remind me of the quote by Ludwig Wittgenstein: “The limits of my language means the limits of my world.”
Of course if you limit yourself only to problems that can be effectively solved by type system, then it may work. It is like limiting yourself only to those text processing tasks where regexs work. Yes, some text processing tasks may be much more effectively solved using a regex. But it is obvious that at some point in a more general case grep can’t replace python. It may be less apparent for compiler vs. python case but the general logic is the same.
Nobody is "limiting" themselves to anything. That's not a counterargument you're making.
We all deploy to production, dude.
Strong static typing (Rust), even only dynamic strong typing + pattern matching (Elixir), are leagues better than Python. Literal 3x - 7x less code and less production errors both in Elixir and Rust, over the course of 5 years.
You're the one limiting yourself. Expand your horizons.
If using python with type annotations, linters like ruff and mypy do a great job at identifying issues. It's no substitute for tests and nor will it give you the same guarantees that rust will at compile time. But I think it improves the base quality of the code.
Yeah I see what you mean, you can always disable specific features, but I think that's a habit mypy tries to enforce. They consider redefining a variable bad practice.
Even in rust you have to be explicit about doing the same thing with an extra "let" statement.
Yeah that's fair enough, and I've lived with it because of how good MyPy is. But I always end with weird variable names like uuids_as_list as a result!
>This meant when we update a function signature we would often incorrectly update call sites, etc.
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?
This is something I watch out for: teams which fear their own code and operate defensively, typically with cargo-cult practices that accumulate even though they themselves aren’t well understood.
When I started, the culture was already engineered to prevent this reluctance. You would hear "the code is fragile, it's going to break. Noone will shout at you for that." This was great. But I would prefer to just not have to "run in eggshells" haha!
It can be solved with static analysis and type inference. Inference can be tricky though, as you have to backtrack and figure out what type of values functions return etc, so type hints/annotations make the job easier for the IDE/tooling developer, but they are not necessary!
> With dynamically typed languages I feel it's better to wait until you've tried to maintain the code for a while before you consider the languages effectiveness.
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.
To extend on this: There was always this implied impression that the original developers were hot because they got stuff up and running really quickly and that all the newer developers were lukewarm because they weren't getting stuff happening quickly at all, all as a result of the original language choice!
Java is a great language, and the JVM a great platform. I think that the thing which makes Java underrated isn't the language, but rather Java Developers. There are tons of great Java developers, but they are probably great developers in any language. But Java being the language of choice at so many enterprises results in a large number of very low skilled and inadequate Java programmers, who would be bad developers in any language, but specialize in Java.
The JVM is awful. In 2025, it still arm wrestles with the OS on which it runs for memory management and still completely loses its shit should the OS decide to send any portion of its precious memory allocation to swap.
I have mixed feelings about Java. It's a solid feature set, and I really love how InterruptedException was always a thing, so you can generally terminate a thread and it works (a lot of languages don't do this right). I love checked exceptions.
But the spooky action at a distance type annotation hell, needing builders everywhere because of lack of named parameters, poorly conceived generics, nullability not being first class, lambdas being incompatible with checked exceptions, etc. are a pain.
One of my coworkers described Python (specifically in reference to a niche framework, but I think it applies generally) as "a bucket of play-doh filled with broken glass"
I understand your frustrations since you are forced to work within a codebase that is shared with other developers with varying levels of experience. Lua was from the get-go never supposed to be a standalone language, it is more of a complimentary language and if you fail to respect that then it becomes unwieldy, quick. It is extremely easy to shoot yourself in the foot with the language and once bad design decisions creep in it is hurts a LOT. However once you get enough experience with the language you manage stay within the "happy path" (which is EXTREMELY difficult when you are on a team with salaried software engineers with different and often misaligned incentives) it is actually one of the best languages available.
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.
We were using Luajit with our own extensions with our own binding mechanisms that included automatic translation of indices. And we had A LOT of bindings.
There was some "fun" there. Luajit C functions uses space indentation that becomes tabs every 8 spaces, i.e. mixed tabs and spaces. And his custom assembler for the assembly portions.
I personally spent a lot of time "refactoring code to generate less garbage" as we had purposeful garbage collection in our idle time.
One of the advantages with Lua was that everyone could code in it. I.e. for our games all the artists, sound engineers and producers were developing Lua which was super productive.
But the function signature one in particular - that would have saved me a lot of stress on release nights!
Oh wow you were editing the source of LuaJIT? That sounds like a nightmare. I'm pretty sure Mike Pall is the only person who understands that codebase lol.
To be honest I am trying to move away from LuaJIT, now that q66's cffi-lua project exists I don't have a reason to use LuaJIT from a dev productivity perspective. For speed, sure. But for my use-case regular Lua is fast enough and the added features in 5.4 over 5.1 are really nice. Plus having the option to easily edit the Lua source code if I want gives me a lot of comfort, since the codebase is way simpler than LuaJIT's.
I have removed LuaJIT from everything I use other than OpenResty. If I could, I would remove it from OpenResty but that is a huge undertaking
Yeah the garbage collector is one of the things in Lua I really don't like - in Lua 5.4 Roberto added the <close> thing and generational GC but I'm not sure how well these work in practice. I guess I'm lucky enough in that I have never hit the upper limit where a GC cycle totally kills performance and if that ever happens I have the option of rewriting that code in C
Yeah I had a pretty high opinion of Lua when I first used it, then I came back to code I'd written years earlier, and the lack of types just made it a nightmare.
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.
I think that much of game development is unlike a lot of other kinds of programming, where there's often more ad hoc game mechanic prototyping than maintenance. This is where dynamic programming excels. But of course, that consideration needs to be balanced against others.
They mention Luau near the end, and my opinion is that Luau is a significant improvement. Mainly because of the optional typing, but the other features too are each small but impactful quality of life improvements.
I guess I mean both. In that you can take something dynamically typed and add type definitions to make it more typed over time. JavaScript would not be what I'm talking about without the existence of Typescript.
> Much like C++ then — the machine code to which it translates lacks types!
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.
> TypeScript compiler essentially treats types as a lint
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.
This is sadly so; TS's type system is unsound. But so is C#'s, in ways much more egregious that in TS. Despite that, both languages are very usable in practice, and their static checks prevent a very wide range of problems common in languages without a static type system.
If you need bulletproof soundness and JS as the runtime, you have Purescript %)
Which ways you say? As far as I know: both TS and C# can carry hidden nulls; both made the mistake of covariant arrays, but C# actually type checks accesses at runtime; and the other unsound case I know of in C# involves a runtime type check as well. Meanwhile, TS (and Python) allow fully unchecked casts into the wrong type.
> both languages are very usable in practice
Agreed, but I still consider TS too unsound in trivial cases for the claim I replied to, despite its expressive power. I think this industry is lacking severely when it comes to basic software correctness.
> I haven't had a chance to try Elixir's new type system (is it ready yet?)
Sadly no, and it will likely not be fully ready for years still. It's not a funded work and only a few people are working on it (AFAICT) and the core team understandably wants gradual movement and no incompatibilities.
Elixir made me rediscover love for programming and gave me productivity I never dreamed of. But after using it for 9 years, the lack of static typing really started getting on my nerves. There are only so many times you can do manual exhaustive pattern-matching on the hot paths that yell errors in production before you start feeling envious of Rust and Haskell.
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.
I would argue that machine code is typed, but this will be up to interpretation. I.e. you can add two 32 but floating point numbers or two 16 bit integers or store an 8 bit value. It's just doesn't require you to purposefully type pun in some circumstances (e.g. where floating point and integer registers are shared).
A "typed" machine code would imply that you can say "Add these two 32-bit floating points" and the CPU will say "No, I can't, those are 4 8-bit unsigned integers". I don't believe the CPU will ever say that, so it is not typed by any sensible measure. Best you can do is that there may be some registers that can only be used by floating point units and others that can only be used by ints, but even that is really just hardware limitations for performance and not any sort of type assertion; the CPU will happily bit-slam them back and forth without anything like an "exception".
I'd say that instructions are typed, but data are not. You can use an integer arithmetic, bit manipulation, floating point arithmetic, or vector SSE instruction on the very same data in the very same register, and it will just work without any complaints for most bit patterns. A CPU of course does analyze the code, but only the short segment currently in the pipeline, and not for any high-level semantics, just for data dependencies and very local jumps.
So much lua stuff on HN the past few days, I love it.
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.
One big takeaway: a 60k LOC project in Lua is doable, and it will not crumble under its own weight.
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.
Years ago I wrote/maintained a modal console-based email client. It was written with some UI primitives in C++ and the UI actually maintained and controlled by lua.
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.
You can make anything, even assembler, not "crumble under its own weight" if you, the developer, bring enough discipline and care to it.
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.
I read half the article and little is told in it in general. You'd expect some deeper developer reflections on a 60kloc project. Like, much deeper. The part about "spacer" hints that the second half won't surprise either. There's just not enough general xp to make conclusions.
This dev seems really inexperienced and has weird uninformed takes. The "functional vibe" but it's just using boolean logic, the "reference in a table" bugs that would happen in any language but C, the ignorance of type annotations and so much time spend on problems caused by said ignorance...
He may not be super expert, but he doesn't pretend to be. His experience is still valid even if he doesn't really understand what functional programming is yet. (His example isn't just boolean logic.)
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?
The example is not just boolean logic! In Lua logical ops, the last evaluated value is returned. The example makes use of that to assign something other than a bool. Not all languages do that. In Java for example, boolean logic always evaluates to a bool.
I'm not sure which part of that you missed, but maybe don't go too hard on calling others inexperienced based on your takes.
> 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.
> ...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.
Reads tongue in cheek but also to be clear, as a PUC-Rio alum I can say there's no such thing as a collective "pontifical catholic universities" board that determines how programming languages behave or how students and faculty should go about their businesses in a software engineering class...
Almost certainly! The one here in Argentina has campuses in six cities and is well regarded, though it doesn't rank well in worldwide rankings. It has 24000 students at any given time, with alumni including the Queen of the Netherlands and one of the founders of OLX. It seems likely that the number of programming languages designed by one or another professor or student there at one time or another is in the dozens. One repo I found on GitHub uses a dialect of Smalltalk I'm not familiar with, but I don't know if it originates at the university: https://github.com/uca-argentina/2021-bigtalkers/blob/master...
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!
good to see defold win. I prefer the love2D/dragonruby framework ways instead of engine now, but can’t deny defold has it all for 2D: game editor, common game structures provided modularly, deployment, no bloat. I could only wish it was the first engine I used. Life would’ve been so much better!
Roblox has 85 mln daily active users and they use a fork of Lua for most logic. Although most games are very basic, some roleplay games must have tens of thousands of LoC.
Beyond All Reason is a SpringTA fork (hack? build?) like Zero-K? So the underlying engine isn't Lua, but higher level scripting is. I'm pretty sure this is fairly common, or was once.
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.
>This is the second game I've found out recently that is written in Lua. The first one one being - Beyond All Reason.
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.
I am surprised that he did not include all of the Souls games, as they are hugely popular.
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.
YOYOZO, my game that received a "Best Games of 2023" accolade, was also written in Lua. It is only 39KB despite containing two music tracks, physics and particle systems, online high score board, dynamic sounds, two fonts, a tutorial and more. https://news.ycombinator.com/item?id=38372936
I played the demo of Craftomation 101 a while back. It was good! Had a good balance of watching emergent behavior and feeling the need to micro-manage/accelerate the process.
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.
I’ve recently moved to the Neovim but even though I learned Lua enough to use it I never found it ergonomic.
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.
I can write a program that is 1,000,000 lines of code, and a program that is 200 lines of code, and to the end user they would be doing the same thing.
Now, if you start establishing some rules about the type of code I'm allowed to write, then your statement becomes truer. But by no means do people actually follow that in the real world all the time.
>I can write a program that is 1,000,000 lines of code, and a program that is 200 lines of code, and to the end user they would be doing the same thing.
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.
Sure, but, assuming you are actually only counting lines of code and not whitespace or comments, if that end user asks for a new feature, it's probably going to be a lot easier to figure out where to put it in 200 lines than in 1,000,000 lines.
Do you really think LoC does not impact maintainability? How much depends on language and adjacent tooling for things like refactors, but the larger a code base the harder it is to maintain in general.
With dynamically typed languages I feel it's better to wait until you've tried to maintain the code for a while before you consider the languages effectiveness.
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 saw someone describe python as “stressful” for this reason and I couldn’t agree more. It’s difficult to have confidence in any change I make or review. I need to sit down and manually exercise codepaths because I don’t get the guarantees I crave from the language or tooling. While with the small amount of Rust code I’ve written lately I could yolo changes into production with no stress.
Agreed. I had to work in a larger Python codebase after spending a few years with Go and Rust and the drop in logical confidence around the language was remarkable.
I have, roughly, sworn off dynamic languages at this point. Although I have dreams of implementing a firm typed system over Common Lisp.
Same, though my trauma was Ruby. Those Rubyists who were apparently born with the language spec in their heads can do amazing things, but I am a mere mortal who needs to be told I wrote bad code right when I wrote it, not told at 2am on a production server.
do you not test your code?
In a large enough code base, there is no "your code". There is the code you wrote today, there is the code you wrote two years ago, there's all the code people are writing around you.
I change a function's arguments, I'm _pretty_ sure I caught every place it's called (spoiler alert: I didn't, because someone calls functions dynamically based on their names with call_user_func_array, maybe), and I ran the test suite - everything works, and I've fixed what doesn't.
Except some of that old code written 8 years ago didn't have good tests, or didn't have any tests at all, or didn't cover the specific code path.
And now it's 2am on the production server.
Now, you could tell me - Pavel, you're an engineer, you should be sufficiently dedicated to your craft to verify that the tests are testing those paths, you should find all those instances where that function is called (a few dozen times across the codebase), and check that those tests exist and are good. And you're not wrong! I should be doing cleanup in the codebase as I go, washing those dishes while I wait for pasta to boil or whatever...
... but now I've given myself two more actual engineer-weeks of work for a change that just needed to add a flag to a function to make sure only premium users get emails when something happens. My manager will be thrilled to hear it. Do you think I'll get a raise?
I’m assuming that Python code base didn’t have thorough type hints. What if it had? Would Go still feel safer? I know these aren’t checked in runtime, but Python type system seems more thorough than Go’s, so shouldn’t a Python code base fully typed be even safer than Go? If so, why not?
(I know Python type checks aren’t mandatory, but for this question assume that the type checker is running in CI)
Since Python type checking is functionally optional, it implies that somewhere, somehow, someone has opted out, or has used a type checker that differs subtly but unpleasantly from the one you're using. Python's type checker systems are fundamentally a _linter_ more than something like Java or C...or Rust.
It's not about feeling. It's about the theorems you can make about the codebase. With Python the answer actually is ¯\_(ツ)_/¯.
You're hand-waving the insane amount of effort that would be required to type every bit of Python code that gets executed. You get that by default in statically typed languages.
Even then, you're reliant on the correctness of a 3rd party tool vs a 1st party compiler. It's never going to be as good of an experience.
You mean compiler vs client reporting issues? Never safer.
Yes, but in practice, is the difference significant enough to matter? I’m genuinely looking to see if I’m missing anything when favoring Python type system over Go’s.
One difference is that Python's type system is unsound. You can write code that passes `mypy --strict` but still contains functions that, for example, claim to return an `int` but actually return a `list` [0]. AFAIK it's not possible to circumvent Go's type system in such a way.
[0] https://news.ycombinator.com/item?id=43508152
The biggest limitation of Go's static type system vs. Python's type hints system that I can think of would be the lack of union types, with nullability a close second (and it's just a specialized application of union types in Python). An interface in Go can be anything under the hood, though you at least know that, whatever its concrete type, it does implement the methods exactly as defined.
You can definitely circumvent Go's type system with unsafe operations (with FFI also recognized as inherently unsafe) but that's a clear boundary that you know you're crossing (albeit not quite as clear as e.g. in Rust).
It matters the most in practice, actually. Much less production all-hands-on-deck situations.
The fact that there still exist people to whom this is not painfully obvious is despairing me.
Firm like:
I need to spend some quality time with Coalton. I don't think it's _quite_ what I want, but its in the same key.
> I need to sit down and manually exercise codepaths
Isn't that exactly what unit tests are for?
Yeah, that's a common argument for dynamic typing. You're writing tests anyway (right?), and those will catch type errors and many other kinds of error. Why bother with a separate level of checking just for type errors?
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.
Fortunately my compiler writes a large number of unit tests for me, that run at compile time! I call it the "typechecker".
Except now you're writing and maintaining twice the amount of code instead of relying on the compiler and/or type checker to help you catch those errors
Sorry, but I don't agree that static typing is a replacement for unit tests. I can see static languages having fewer unit tests, but it's not going to eliminate them.
Static typing is a replacement for unit tests aimed to catch type bugs. Also, no one has 100% code coverage so might as we get some guarantees for granted.
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.
It's obviously not a replacement. You can get the types right but the values wrong due to faulty logic.
Sure, but only some of the unit tests are about values. Others, at least in my experience, are any handing various aspects of the implied types of values, and those can largely be removed.
Moreover, a good type system can also force the values to be right by enforcing certain invariants directly in the type system. For example, let's say I have a function `deleteProjectAs(user, project)` that deletes a project, but it only works if the user is an admin, otherwise it throws an error. I can write a bunch of tests that validate that this function checks that the user is an admin in all sorts of different cases, but with a type system I can write something like `deleteProjectAsUser(user: Admin, project: Project)`, and this guarantees at the type level that no non-Admin user can delete a project.
The point here is not that types can replace all tests, but that well-designed types can get rid of a lot of them.
I agree. My post was unnecessary; I did not realize the response was talking specifically about type bugs.
You're tearing down a straw man. Your parent poster did not say it eliminates tests. He said static typing mean less tests. He didn't say static typing is a replacement for tests either.
Why are you doing double misrepresentation?
More honest discussion tactics, please.
When using dynamic languages, either minimize code dependencies / function calls and complexity or ensure high test coverage.
Do you believe that Rust's type system is as flexible, powerful, and easy to maintain as unit tests in Python?
One of the big advantages of Rust's type system is that, if you decide you want to change something (add a parameter, give a type a lifetime, rewrite an entire module), you can just do that, and then follow the errors until they're all gone. Often, once the types have been fixed again, the result will work first time when you try and run it.
In this regard, Rust (and other languages where lots of data invariants can be encoded in the type system) is very flexible and easy to maintain indeed, because you can easily make changes, even in very old or poorly-maintained code, without having to worry about the consequences. Moreover, rather than writing all the unit tests yourself, it's as if the compiler is writing the unit tests for you.
In fairness, you can't encode everything in the type system, so you still need unit tests in top of that, but in my experience you can get away with far fewer. In general, I would say that Rust's type system, when combined with unit tests, is far more flexible, powerful, and easy to maintain than dynamic Python with only unit tests.
I write and test a lot of both rust and python, so I can say quite confidently:
1. Of course a type system is not as "flexible" as arbitrary test code.
2. Compiler-enforced type safety is many orders of magnitude easier to maintain than the equivalent unit tests
3. Defining rigorously enforced invariants with a type system is far, far more powerful than hoping you remembered to test all the important cases.
Your 2-3 points remind me of the quote by Ludwig Wittgenstein: “The limits of my language means the limits of my world.”
Of course if you limit yourself only to problems that can be effectively solved by type system, then it may work. It is like limiting yourself only to those text processing tasks where regexs work. Yes, some text processing tasks may be much more effectively solved using a regex. But it is obvious that at some point in a more general case grep can’t replace python. It may be less apparent for compiler vs. python case but the general logic is the same.
So you asked a question, didn't like the answer, and decided to just start insulting people instead?
No disrespect intended. I’m making purely technical point.
Nobody is "limiting" themselves to anything. That's not a counterargument you're making.
We all deploy to production, dude.
Strong static typing (Rust), even only dynamic strong typing + pattern matching (Elixir), are leagues better than Python. Literal 3x - 7x less code and less production errors both in Elixir and Rust, over the course of 5 years.
You're the one limiting yourself. Expand your horizons.
No, it's more flexible, more powerful, and easier to maintain than unit tests in Python.
If using python with type annotations, linters like ruff and mypy do a great job at identifying issues. It's no substitute for tests and nor will it give you the same guarantees that rust will at compile time. But I think it improves the base quality of the code.
The thing I find annoying with MyPt is trying to tell it I'm doing variable shadowing.
E.g. X is a list of strings Translate X to a list of indices Translate X back to a list of strings.
In that paragraph the input and output types are the same, but not complains about the second line.
I always have to introduce a variable with a new name.
Yeah I see what you mean, you can always disable specific features, but I think that's a habit mypy tries to enforce. They consider redefining a variable bad practice.
Even in rust you have to be explicit about doing the same thing with an extra "let" statement.
Yeah that's fair enough, and I've lived with it because of how good MyPy is. But I always end with weird variable names like uuids_as_list as a result!
>This meant when we update a function signature we would often incorrectly update call sites, etc.
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?
This is something I watch out for: teams which fear their own code and operate defensively, typically with cargo-cult practices that accumulate even though they themselves aren’t well understood.
When I started, the culture was already engineered to prevent this reluctance. You would hear "the code is fragile, it's going to break. Noone will shout at you for that." This was great. But I would prefer to just not have to "run in eggshells" haha!
It can be solved with static analysis and type inference. Inference can be tricky though, as you have to backtrack and figure out what type of values functions return etc, so type hints/annotations make the job easier for the IDE/tooling developer, but they are not necessary!
> With dynamically typed languages I feel it's better to wait until you've tried to maintain the code for a while before you consider the languages effectiveness.
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.
To extend on this: There was always this implied impression that the original developers were hot because they got stuff up and running really quickly and that all the newer developers were lukewarm because they weren't getting stuff happening quickly at all, all as a result of the original language choice!
This is what makes Java underrated these years. Some annoying stuff pays off over a decade several times. You can make insane complexity with ease.
Java is a great language, and the JVM a great platform. I think that the thing which makes Java underrated isn't the language, but rather Java Developers. There are tons of great Java developers, but they are probably great developers in any language. But Java being the language of choice at so many enterprises results in a large number of very low skilled and inadequate Java programmers, who would be bad developers in any language, but specialize in Java.
The JVM is awful. In 2025, it still arm wrestles with the OS on which it runs for memory management and still completely loses its shit should the OS decide to send any portion of its precious memory allocation to swap.
The language, is beautiful.
dont swap
I have mixed feelings about Java. It's a solid feature set, and I really love how InterruptedException was always a thing, so you can generally terminate a thread and it works (a lot of languages don't do this right). I love checked exceptions.
But the spooky action at a distance type annotation hell, needing builders everywhere because of lack of named parameters, poorly conceived generics, nullability not being first class, lambdas being incompatible with checked exceptions, etc. are a pain.
One of my coworkers described Python (specifically in reference to a niche framework, but I think it applies generally) as "a bucket of play-doh filled with broken glass"
Does said coworker use mypy?
Yes. Mypy helps but isn't nearly enough, especially for a gradually typed codebase.
I understand your frustrations since you are forced to work within a codebase that is shared with other developers with varying levels of experience. Lua was from the get-go never supposed to be a standalone language, it is more of a complimentary language and if you fail to respect that then it becomes unwieldy, quick. It is extremely easy to shoot yourself in the foot with the language and once bad design decisions creep in it is hurts a LOT. However once you get enough experience with the language you manage stay within the "happy path" (which is EXTREMELY difficult when you are on a team with salaried software engineers with different and often misaligned incentives) it is actually one of the best languages available.
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.
We were using Luajit with our own extensions with our own binding mechanisms that included automatic translation of indices. And we had A LOT of bindings.
There was some "fun" there. Luajit C functions uses space indentation that becomes tabs every 8 spaces, i.e. mixed tabs and spaces. And his custom assembler for the assembly portions.
I personally spent a lot of time "refactoring code to generate less garbage" as we had purposeful garbage collection in our idle time.
One of the advantages with Lua was that everyone could code in it. I.e. for our games all the artists, sound engineers and producers were developing Lua which was super productive.
But the function signature one in particular - that would have saved me a lot of stress on release nights!
Oh wow you were editing the source of LuaJIT? That sounds like a nightmare. I'm pretty sure Mike Pall is the only person who understands that codebase lol.
To be honest I am trying to move away from LuaJIT, now that q66's cffi-lua project exists I don't have a reason to use LuaJIT from a dev productivity perspective. For speed, sure. But for my use-case regular Lua is fast enough and the added features in 5.4 over 5.1 are really nice. Plus having the option to easily edit the Lua source code if I want gives me a lot of comfort, since the codebase is way simpler than LuaJIT's.
I have removed LuaJIT from everything I use other than OpenResty. If I could, I would remove it from OpenResty but that is a huge undertaking
Yeah the garbage collector is one of the things in Lua I really don't like - in Lua 5.4 Roberto added the <close> thing and generational GC but I'm not sure how well these work in practice. I guess I'm lucky enough in that I have never hit the upper limit where a GC cycle totally kills performance and if that ever happens I have the option of rewriting that code in C
Yeah I had a pretty high opinion of Lua when I first used it, then I came back to code I'd written years earlier, and the lack of types just made it a nightmare.
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.
> It really could use a fully statically typed layer that compiles down to Lua.
That's Teal: https://github.com/teal-language/tl
I think that much of game development is unlike a lot of other kinds of programming, where there's often more ad hoc game mechanic prototyping than maintenance. This is where dynamic programming excels. But of course, that consideration needs to be balanced against others.
My big Lua codebase was a gamedev codebase, haha!
>when interfacing between C and Lua
Except for the indexing mismatch, I've found calling Lua from C and vise-verse very easy.
you might like this one: https://github.com/ast-grep/ast-grep ... it sounds like you'd get some mileage out of it.
They mention Luau near the end, and my opinion is that Luau is a significant improvement. Mainly because of the optional typing, but the other features too are each small but impactful quality of life improvements.
> dynamically typed languages like Python or Typescript
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.
I guess I mean both. In that you can take something dynamically typed and add type definitions to make it more typed over time. JavaScript would not be what I'm talking about without the existence of Typescript.
TypeScript is sort of "dynamically typed but statically verified".
Much like C++ then — the machine code to which it translates lacks types!
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.
> Much like C++ then — the machine code to which it translates lacks types!
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.
> TypeScript compiler essentially treats types as a lint
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).
> and very much rejects ill-typed programs
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.
This is sadly so; TS's type system is unsound. But so is C#'s, in ways much more egregious that in TS. Despite that, both languages are very usable in practice, and their static checks prevent a very wide range of problems common in languages without a static type system.
If you need bulletproof soundness and JS as the runtime, you have Purescript %)
> in ways much more egregious that in TS
Which ways you say? As far as I know: both TS and C# can carry hidden nulls; both made the mistake of covariant arrays, but C# actually type checks accesses at runtime; and the other unsound case I know of in C# involves a runtime type check as well. Meanwhile, TS (and Python) allow fully unchecked casts into the wrong type.
> both languages are very usable in practice
Agreed, but I still consider TS too unsound in trivial cases for the claim I replied to, despite its expressive power. I think this industry is lacking severely when it comes to basic software correctness.
> I haven't had a chance to try Elixir's new type system (is it ready yet?)
Sadly no, and it will likely not be fully ready for years still. It's not a funded work and only a few people are working on it (AFAICT) and the core team understandably wants gradual movement and no incompatibilities.
Elixir made me rediscover love for programming and gave me productivity I never dreamed of. But after using it for 9 years, the lack of static typing really started getting on my nerves. There are only so many times you can do manual exhaustive pattern-matching on the hot paths that yell errors in production before you start feeling envious of Rust and Haskell.
You can lie to TypeScript extremely easily in a way that you can't do in strongly typed languages.
Even in a strongly typed language like Java or C#, nothing stops `(string)(object)42`. It all compiles and fails at runtime, like TypeScript.
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.
I think they are confused by the tslint project, which is different than tsc and is not supported by Microsoft
I used tsc directly to develop https://github.com/LoganDark/waifu2x-unlimited. I have experience with tsc.
Or maybe even https://github.com/bloomberg/ts-blank-space
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.
I would argue that machine code is typed, but this will be up to interpretation. I.e. you can add two 32 but floating point numbers or two 16 bit integers or store an 8 bit value. It's just doesn't require you to purposefully type pun in some circumstances (e.g. where floating point and integer registers are shared).
A "typed" machine code would imply that you can say "Add these two 32-bit floating points" and the CPU will say "No, I can't, those are 4 8-bit unsigned integers". I don't believe the CPU will ever say that, so it is not typed by any sensible measure. Best you can do is that there may be some registers that can only be used by floating point units and others that can only be used by ints, but even that is really just hardware limitations for performance and not any sort of type assertion; the CPU will happily bit-slam them back and forth without anything like an "exception".
"And even other than that, machine code isn't dynamically typed because it's not typed at all."
Well, we have bytes, words, doublewords and quadwords on the machine level. They are usually referred to as data types in the processor manuals.
I'd say that instructions are typed, but data are not. You can use an integer arithmetic, bit manipulation, floating point arithmetic, or vector SSE instruction on the very same data in the very same register, and it will just work without any complaints for most bit patterns. A CPU of course does analyze the code, but only the short segment currently in the pipeline, and not for any high-level semantics, just for data dependencies and very local jumps.
So much lua stuff on HN the past few days, I love it.
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.
One big takeaway: a 60k LOC project in Lua is doable, and it will not crumble under its own weight.
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.
Years ago I wrote/maintained a modal console-based email client. It was written with some UI primitives in C++ and the UI actually maintained and controlled by lua.
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 will not crumble under its own weight
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.
You can make anything, even assembler, not "crumble under its own weight" if you, the developer, bring enough discipline and care to it.
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.
> LuaJIT is not mentioned even once
Defold uses LuaJIT (except for web which I think uses Lua 5.1 compiled to wasm?), so it's taken for granted.
I read half the article and little is told in it in general. You'd expect some deeper developer reflections on a 60kloc project. Like, much deeper. The part about "spacer" hints that the second half won't surprise either. There's just not enough general xp to make conclusions.
60k? try Roblox’s 60bajillion!
Roblox introduced LuaU to get static typing
Almost as many lines as my Neovim config.
But not nearly as many as my Emacs config.
Roughly 60k lines more than my Helix config.
How do you configure awesome plugins for helix then?
I fork the editor and write them in myself. This way I can boast about my tiny config while ignoring the tens of hours of hacking the editor itself
Did I miss something? Plugins for helix? Since when?
Likely soon: https://github.com/helix-editor/helix/pull/8675#issuecomment...
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.
obviously pre-configured to be awesome already!
This made me laugh.
This dev seems really inexperienced and has weird uninformed takes. The "functional vibe" but it's just using boolean logic, the "reference in a table" bugs that would happen in any language but C, the ignorance of type annotations and so much time spend on problems caused by said ignorance...
He may not be super expert, but he doesn't pretend to be. His experience is still valid even if he doesn't really understand what functional programming is yet. (His example isn't just boolean logic.)
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?
The example is not just boolean logic! In Lua logical ops, the last evaluated value is returned. The example makes use of that to assign something other than a bool. Not all languages do that. In Java for example, boolean logic always evaluates to a bool.
I'm not sure which part of that you missed, but maybe don't go too hard on calling others inexperienced based on your takes.
It's an unexpectedly funny interview:
> 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.
(2024) Discussion ~at the time (321 points, 260 comments) https://news.ycombinator.com/item?id=40538540
I am using godot, which uses gdscript, which is known to be a slow language.
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.
Heh:
> ...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.
Reads tongue in cheek but also to be clear, as a PUC-Rio alum I can say there's no such thing as a collective "pontifical catholic universities" board that determines how programming languages behave or how students and faculty should go about their businesses in a software engineering class...
Are there any other programming languages designed by Pontifical Catholic Universities?
Almost certainly! The one here in Argentina has campuses in six cities and is well regarded, though it doesn't rank well in worldwide rankings. It has 24000 students at any given time, with alumni including the Queen of the Netherlands and one of the founders of OLX. It seems likely that the number of programming languages designed by one or another professor or student there at one time or another is in the dozens. One repo I found on GitHub uses a dialect of Smalltalk I'm not familiar with, but I don't know if it originates at the university: https://github.com/uca-argentina/2021-bigtalkers/blob/master...
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!
Interesting, thanks!
Interesting article, although I am confused by the section referencing 'functional vibes' as the examples given just looks like standard code.
The functional code isn't reassigning the same variable. The and/or have something that looks like an implicit return.
Eight space tabs. My eyes! The goggles they do nothing!
good to see defold win. I prefer the love2D/dragonruby framework ways instead of engine now, but can’t deny defold has it all for 2D: game editor, common game structures provided modularly, deployment, no bloat. I could only wish it was the first engine I used. Life would’ve been so much better!
Roblox has 85 mln daily active users and they use a fork of Lua for most logic. Although most games are very basic, some roleplay games must have tens of thousands of LoC.
This is the second game I've found out recently that is written in Lua. The first one one being - Beyond All Reason.
Beyond All Reason is a SpringTA fork (hack? build?) like Zero-K? So the underlying engine isn't Lua, but higher level scripting is. I'm pretty sure this is fairly common, or was once.
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.
Here they are:
https://github.com/beyond-all-reason/Beyond-All-Reason
https://github.com/ZeroK-RTS/Zero-K
I can't recommend Zero-K enough. It plays like a dream. Super fun at all levels. Great 8v8 clashes of robots. Unbeatable price ($0). Great dev blogs.
https://store.steampowered.com/app/334920/ZeroK/
The dev blogs: https://zero-k.info/mediawiki/Cold_Takes
Also Supreme Commander
Recently released, Moonring and Balatro are both written in Lua, and I think both with LÖVE.
>This is the second game I've found out recently that is written in Lua. The first one one being - Beyond All Reason.
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.
Yeah, this presentation by Roberto Ierusalimschy (one of Lua's three authors) lists over 50 games that use Lua (slide #9):
https://www.inf.puc-rio.br/~roberto/talks/curryon2017.pdf
I am surprised that he did not include all of the Souls games, as they are hugely popular.
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.
YOYOZO, my game that received a "Best Games of 2023" accolade, was also written in Lua. It is only 39KB despite containing two music tracks, physics and particle systems, online high score board, dynamic sounds, two fonts, a tutorial and more. https://news.ycombinator.com/item?id=38372936
LOVE is a popular Lua game framework, so quite a few indie games are written in it.
Most of Heroes of Newerth's in-game logic is written in Lua.
Grim fandango too
I played the demo of Craftomation 101 a while back. It was good! Had a good balance of watching emergent behavior and feeling the need to micro-manage/accelerate the process.
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.
I’ve recently moved to the Neovim but even though I learned Lua enough to use it I never found it ergonomic.
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.
Since when is LoC some kind of measurement?
Last 50 years?
Have you studied Software Engineering? They discuss LOC in depth and many academic papers on KLOC are in SE literature.
I can write a program that is 1,000,000 lines of code, and a program that is 200 lines of code, and to the end user they would be doing the same thing.
Now, if you start establishing some rules about the type of code I'm allowed to write, then your statement becomes truer. But by no means do people actually follow that in the real world all the time.
The number was given just so we have a sense of scale of the project being talked about. Its not a competition nor are measures being made.
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 can write a program that is 1,000,000 lines of code, and a program that is 200 lines of code, and to the end user they would be doing the same thing.
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.
You're the only person confused about what's meant by LOC here
Sure, but, assuming you are actually only counting lines of code and not whitespace or comments, if that end user asks for a new feature, it's probably going to be a lot easier to figure out where to put it in 200 lines than in 1,000,000 lines.
To an end user those programs may be the same, but to a software engineer working on the programs they are very different.
It’s not a great metric. But it does communicate something about the scale and complexity of a codebase.
You can assume the measurement is “Lines of Code that matter” then.
Do you really think LoC does not impact maintainability? How much depends on language and adjacent tooling for things like refactors, but the larger a code base the harder it is to maintain in general.