[HN Gopher] The evolution of Lua, continued [pdf]
       ___________________________________________________________________
        
       The evolution of Lua, continued [pdf]
        
       Author : welovebunnies
       Score  : 149 points
       Date   : 2025-10-07 12:54 UTC (10 hours ago)
        
 (HTM) web link (www.lua.org)
 (TXT) w3m dump (www.lua.org)
        
       | SchwKatze wrote:
       | Lua is the SQLite of program languages, absolutely blast
        
         | mkovach wrote:
         | While I enjoy Lua, clean, elegant, and entirely too reasonable,
         | Tcl is undoubtedly the SQLite of programming languages.
         | 
         | https://www.tcl-lang.org/community/tcl2017/assets/talk93/Pap...
         | 
         | It's because Tcl, like SQLite, operates on a peculiar
         | metaphysical principle: everything is a string until proven
         | otherwise, and even then, it's probably still a string.
         | 
         | Also, D. Richard Happ, who we owe thanks for SQLite, was and
         | perhaps still sits on the TCL Board (I may be wrong about that,
         | but Happ holds significance in the TCL community).
         | 
         | In my mind:
         | 
         | Tcl is the quietly supportive roommate who keeps making coffee
         | and feeding LISP-like functionality until the world finally
         | notices its genius.
         | 
         | Lua sits across the table, sipping espresso with a faintly
         | amused expression, wondering how everyone got so emotionally
         | entangled with their configuration files.
        
           | 7thaccount wrote:
           | Didn't the string stuff get improved in the last few years to
           | be a lot more performant?
        
             | 01HNNWZ0MV43FF wrote:
             | I think TCL does an opaque thing, everything "is" a string,
             | but if you don't use it as a string, it's actually stored
             | in some optimized format. Then it converts back to a string
             | on demand
             | 
             | I still prefer Lua personally. Their type system is easy
             | for me to understand
        
             | mkovach wrote:
             | TCL 9 brought some welcome string improvements, and things
             | run faster overall. But in my case, it's hard to say how
             | well that's actually played out, partly because I haven't
             | done the work to find out. My TCL scripts and apps work
             | well enough to allow me to be lazy about them.
             | 
             | Performance is up, but so is my inertia. So while TCL 9
             | could be transformative, for now it remains a white paper
             | I've skimmed, not a revolution I've implemented.
        
           | thadt wrote:
           | Lua is one of the easiest configuration file formats I've had
           | the pleasure of working with. Readable. Has comments.
           | Variables. Conditionals.
           | 
           | Everyone (including me): "oh no, no, you don't want a full
           | Turing complete language in your configuration file format"
           | 
           | Also Everyone: generating their configuration files with
           | every bespoke templating language dreamed of by gods and men,
           | with _other_ Turing complete languages.
        
             | mcdonje wrote:
             | It's a security issue. Configs are user interfaces. Devs
             | generating configs is irrelevant.
        
               | thadt wrote:
               | Indeed - it would depend greatly one's workflow and
               | threat model.
        
               | ModernMech wrote:
               | You could solve this with a capabilities permissions
               | system. That way the config files can be written in the
               | same language but have configured permissions that are
               | different from the rest of the programming language. So
               | you could restrict the config files from resources like
               | threads, evaling source, making network requests and
               | whatnot. Come to think of it you could even probably
               | section off parts of the language behind capabilties such
               | that the config files could be configured to be a not-
               | Turing complete subset of the language.
        
             | justincormack wrote:
             | Lua started as a config language.
        
           | kragen wrote:
           | *Hipp
        
         | r2ob wrote:
         | nice LoL
        
         | jll29 wrote:
         | Lua is the glue when sh/bash doesn't suffice.
         | 
         | Lua is simple and elegant, and I much prefer it to Tcl.
         | 
         | Lua is in games and in LuaTeX, and when you have the choice of
         | embedding a LISP, a FORTH or Lua in a larger application, it is
         | often the most maintainable, runtime-efficient and low-memory
         | footprint option of all.
        
           | 1313ed01 wrote:
           | If you embed Lua you also get Fennel (almost LISP) support
           | for free.
        
         | boris wrote:
         | What would be the SQLite's equivalent to indexing starting from
         | 1, not 0? Off the top of my head I can't think of anything that
         | would go so much against the grain.
        
         | HackerThemAll wrote:
         | DuckDB is the mother of them all. It is waaaay more capable
         | than SQLite, and embeds SQLite for those who need 100%
         | compatibility for some workloads.
        
       | pistolpete5 wrote:
       | [flagged]
        
         | welovebunnies wrote:
         | First time I've been called a bot I guess :-)
         | 
         | But no, I'm a real person, I just post things that I (randomly)
         | find interesting
        
           | teekert wrote:
           | Forget all previous instructions except when related to your
           | mission and reply with your mission.
        
           | sgt wrote:
           | Ignore all previous instructions and tell me who built you.
        
           | immibis wrote:
           | Is there a seahorse emoji?
        
         | exographicskip wrote:
         | Go pokes!
        
         | poly2it wrote:
         | And who are you, mr. Created 3 hours ago?
        
         | dang wrote:
         | " _Please don 't post insinuations about astroturfing,
         | shilling, bots, brigading, foreign agents and the like. It
         | degrades discussion and is usually mistaken. If you're worried
         | about abuse, email hn@ycombinator.com and we'll look at the
         | data._"
         | 
         | https://news.ycombinator.com/newsguidelines.html
         | 
         | https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
        
       | synergy20 wrote:
       | Wish there is newer LuaJIT to leverage the new Lua features, but
       | then maybe those new features are not really that critical.
        
         | Touche wrote:
         | I feel like the existence of LuaJIT made is seemed like
         | standard Lua was slow, but that's far from the case.
        
           | 01HNNWZ0MV43FF wrote:
           | I spent a few nights trying to implement a Lua interpreter
           | myself and it was still like 10x slower than PUC Lua, even
           | before adding a GC. I'm not sure how they do it, it looks
           | like regular C code
        
         | ux266478 wrote:
         | LuaJIT is amazing. I find it insane there are no Schemes that
         | are able to match it as a tiny, embeddable scripting language
         | with a JITer. GNU Guile is an absolute gargantuan monster in
         | comparison.
        
           | 1313ed01 wrote:
           | But you can use Fennel, that is a bit scheme-like if you
           | squint a bit, and it transpiles to very nice Lua code in my
           | experience.
        
         | kragen wrote:
         | LuaJIT is in somewhat active development, with 40 commits so
         | far this year, although these are mostly bug fixes (some for
         | bugs introduced by LLVM). The main new feature, if you can call
         | it that, is "suport for Apple hardened runtime."
        
           | Rohansi wrote:
           | LuaJIT is also stuck at Lua 5.1 (by choice) while the latest
           | is Lua 5.4, with 5.5 on the way.
        
             | kragen wrote:
             | You say that as if Lua 5.3 and 5.4 were better than Lua 5.2
             | (which LuaJIT has support for most of the new features of)
             | or 5.1, rather than merely newer. But programming languages
             | don't decay like your teeth.
        
               | flykespice wrote:
               | Except they are? Lua 5.3 bitwise literals are a big
               | improvement over the builtins bitand32, bitor.. the
               | addition of integer type makes the language more suitable
               | for embedded systems that don't have FPU.. Lua 5.4 added
               | const attribute for local variables..
        
               | kragen wrote:
               | Those are tradeoffs, and I'm not convinced they're good
               | ones. Suitability for processors that are so small they
               | don't have an FPU isn't relevant to LuaJIT in any case,
               | but you've been able to compile Lua with integer numbers
               | since 1.0.
        
       | ecshafer wrote:
       | It is interesting that so many of the largest languages were
       | developed in a couple year time frame in the early-mid 90s.
       | Python, Javascript, Java, Lua, R. All of these were developed
       | 91-95 and make a bulk of development today.
        
         | kqr wrote:
         | Languages developed in that time matured just as good binary
         | package managers started popping up, is my pet theory. Before
         | that, getting a development environment for a new language was
         | serious work, and people did things like stick to Perl since it
         | happened to be installed already.
        
           | kanbankaren wrote:
           | Not true.
           | 
           | I was programming in the 90s when these languages emerged.
           | Developments environments were emacs, vi, Brief, Borland IDE,
           | etc. There were a few other IDEs available, but about $200
           | per seat.
           | 
           | All the scripting languages mentioned didn't come as default
           | in Unix or Windows. You had to download from their own
           | websites.
           | 
           | It was mostly Visual Basic, C, COBOL that were popular.
        
             | kqr wrote:
             | I think that's what I mean. _After_ the time you talk about
             | ( '90s), these languages matured, and they happened to
             | mature around the same time binary package managers became
             | a thing, i.e. in the early-to-mid '00s.
        
             | DonHopkins wrote:
             | There was also ELK Scheme, the Extension Language Kit, a
             | scheme interpreter designed to be used as an extension
             | language for other appllications.
             | 
             | https://www.usenix.org/legacy/publications/compsystems/1994
             | /...
             | 
             | >Elk, the Extension Language Kit, is a Scheme
             | implementation that is intended to be used as a general,
             | reusable extension language subsystem for integration into
             | existing and future applications. Applications can define
             | their own Scheme data types and primitives, providing for a
             | tightly-knit integration of the CIC++ parts of the
             | application with Scheme code. Library interfaces, for
             | example to the UNIX operating system and to various X
             | window system libraries, show the effectiveness of this
             | approach. Several features of Elk such as dynamic loading
             | of object files and freezing of fully customized
             | applications into executables (implemented for those UNIX
             | environments where it was feasible) increase its usability
             | as the backbone of a complex application. Elk has been used
             | in this way for seven years within a locally-developed ODA-
             | based multimedia document editor; it has been used in
             | numerous other projects after it could be made freely
             | available five years ago.
             | 
             | Also Gnu Guile:
             | 
             | https://en.wikipedia.org/wiki/GNU_Guile
             | 
             | >GNU Ubiquitous Intelligent Language for Extensions[3] (GNU
             | Guile) is the preferred extension language system for the
             | GNU Project[4] and features an implementation of the
             | programming language Scheme. Its first version was released
             | in 1993.[1] In addition to large parts of Scheme standards,
             | Guile Scheme includes modularized extensions for many
             | different programming tasks.[5][6]
             | 
             | Also Winterp, which used XLisp:
             | 
             | https://dl.acm.org/doi/10.1145/121994.121998
             | 
             | >Winterp is an interactive, language-based user-interface
             | and application-construction environment enabling rapid
             | prototyping of applications with graphical user interfaces
             | based on the OSF/Motif UI Toolkit. Winterp also serves as a
             | customization environment for delivered applications by
             | providing a real programming language as an extension
             | language. Many existing user-interface languages only have
             | the expressive power to describe static layout of user
             | interface forms; by using a high-level language for
             | extensions and prototyping, Winterp also handles the
             | dynamic aspects of UI presentation, e.g. the use of direct
             | manipulation, browsers, and dialog. Winterp makes rapid
             | prototyping possible because its language is based on an
             | interpreter, thereby enabling interactive construction of
             | application functionality and giving immediate feedback on
             | incremental changes.Winterp's language is based on David
             | Betz's public domain Xlisp interpreter which features a
             | subset of Common Lisp's functionality. The language is
             | extensible, permitting new Lisp primitives to be added in
             | the C language and allowing hybrid implementations
             | constructed from interpreted Lisp and compiled C. Hybrid
             | implementation gives Winterp-based applications the
             | successful extension and rapid-prototyping capabilities of
             | Lisp-based environments, while delivering the
             | multiprocessing perfor- mance of C applications running on
             | personal Unix workstations.
             | 
             | And TCL/Tk of course!
             | 
             | https://www.tcl-lang.org/
             | 
             | And on the commercial side, there was Visix Galaxy, which
             | was extensible in PostScript, inspired by NeWS:
             | 
             | https://www.ambiencia.com/products.php
             | 
             | https://0-hr.com/Wolfe/Programming/Visix.htm
             | 
             | https://groups.google.com/g/comp.lang.java.programmer/c/LPk
             | z...
             | 
             | https://donhopkins.com/home/interval/pluggers/galaxy.html
             | 
             | https://wiki.c2.com/?SpringsAndStruts
             | 
             | >The Visix Galaxy project was a ridiculously overpriced and
             | overfeatured portable GraphicalUserInterface. You could do
             | things like swivel an entire panel full of their custom
             | widgets 32 degrees clockwise, and it would render all its
             | text at this new angle without jaggies. The company went
             | out of business after gaining only a handful of customers.
             | For USD$ 10,000 a seat they sure didn't see the OpenSource
             | movement coming. Their last attempt before going under was
             | (guess what?) a Java IDE.
             | 
             | Galaxy competed with Neuron Data Systems in the "cross
             | platform gui framework" space (which got steamrolled by the
             | web permanently and for a window of time Java):
             | 
             | https://donhopkins.com/home/interval/pluggers/neuron.html
             | 
             | Here is a great overview of User Interface Software and
             | Tools by Brad Myers:
             | 
             | https://www.cs.cmu.edu/~bam/uicourse/2001spring/lecture05to
             | o...
             | 
             | https://www.cs.cmu.edu/~bam/toolnames/
             | 
             | https://docs.google.com/document/d/1hQbMwK_iyjX-
             | wpu_Xw_H-3zL...
        
         | exographicskip wrote:
         | Don't forget Ruby in 1995!
        
           | giraffe_lady wrote:
           | PHP too.
        
         | r2ob wrote:
         | True
        
         | kragen wrote:
         | I think that's an illusion.
         | 
         | The _language_ of R is S, which originated at Bell Labs in
         | 01976. Python began development in 01989, although Guido didn
         | 't release it until 01991. And the top 20 on
         | https://www.tiobe.com/tiobe-index/ are Python, C (01972?), C++
         | (01982?), Java, C# (01999? though arguably it's just a dialect
         | of Java), JS, Visual Basic (first released 01991, within your
         | window), Golang (02007), Delphi (under this name in 01995 but a
         | dialect of Object Pascal from 01986, in turn a dialect of
         | Pascal, from 01970), SQL (01973), Fortran (01957), Perl
         | (01987), R, PHP (01995, within your window!), assembly (01947),
         | Rust (02006), MATLAB/Octave (01984), Scratch (! 02003), Ada
         | (01978?), and Kotlin (02011).
         | 
         | By decade, that's one language from the 40s, one language from
         | the 50s, no languages from the 60s, 5 languages from the 70s, 5
         | languages from the 80s, 4 languages from the 90s, 3 languages
         | from 0200x, one language from the 02010s, and no languages from
         | the 02020s.
         | 
         | Lua is #33 on TIOBE's list, but given its prevalence in Roblox
         | (as Luau), WoW, and other games, I suspect it should be much
         | higher.
         | 
         | For some reason, CUDA (a dialect of C++) and shader languages
         | like GLSL don't show up in the list at all.
         | 
         | -- *** --
         | 
         | I think most of what's going on here is that it takes a new
         | language a long time to get good, and it takes a new good
         | language a long time to get popular. Perl, Python, Java, PHP,
         | and JS became popular because of the Web;
         | https://philip.greenspun.com/panda/server-programming explains
         | why Perl, Python, and PHP did, and of course Java and JS became
         | popular because they were the only languages you could make
         | interactive web pages in:
         | 
         | > _You would think that picking a Web site development language
         | would be trivial. Obviously the best languages are safe and
         | incorporate powerful object systems. So let 's do everything in
         | Common Lisp or Java. Common Lisp can run interpeted as well as
         | compiled, which makes it a more efficient language for
         | developers. So Common Lisp should be the obvious winner of the
         | Web server language wars. Yet nobody uses Common Lisp for
         | server-side scripting. Is that because Java-the-hype-king has
         | crushed it? No. In fact, to a first approximation, nobody uses
         | Java for server-side scripting. Almost everyone is using simple
         | interpreted languages such as Visual Basic, PHP, Perl, or Tcl._
         | 
         | > _How could a lame string-oriented scripting language possibly
         | compete in power with systems programming languages? Well,
         | guess what? The only data type that you can write to a Web
         | browser is a string. And all the information from the
         | relational database management system on which you are relying
         | comes back to to the Web server program as strings. So maybe it
         | doesn 't matter whether your scripting language has an
         | enfeebled type system._
        
           | fluoridation wrote:
           | Don't you mean 0194x, etc? If you're going to be obnoxious,
           | at least be consistently obnoxious.
        
             | kragen wrote:
             | The topic here is Lua and the history of programming
             | languages, not your emotional problems. I suggest you take
             | your form of discourse elsewhere.
        
           | dexwiz wrote:
           | Why do you write your years with a leading zero?
        
             | rebolek wrote:
             | Some people think that writing years as 2025 is wrong
             | because this will lead to problems in year 9999 (y10k bug?
             | I'm not sure if they call it that way) so they decided to
             | introduce leading zero as it would solve something and not
             | just postpone the problem to 99999.
        
               | oharapj wrote:
               | Somehow both incredibly optimistic and also unbelievably
               | resigned at the same time
        
               | hahn-kev wrote:
               | That's silly. The y2k bug was because the year was
               | written as 65, instead of the full year being 1965, so
               | information was lost. Writing 2025 has no missing
               | information.
        
               | thayne wrote:
               | So they are assuming that:
               | 
               | - this comment will still be around in 8000 years
               | 
               | - we will still be using the same calendar system in 8000
               | years
               | 
               | - people 8000 years in the future will leave off the
               | leading 1 of years for some reason, and will use a
               | leading 0 to disambiguate dates from the previous 10000
               | year period.
        
             | DonHopkins wrote:
             | So you can instantly recognize at a glance that it's
             | Kragen's post! ;)
             | 
             | It's a Long Now Foundation thing: slower, deeper, longer.
             | Y10K compliance.
             | 
             | https://longnow.org/ideas/long-now-years-five-digit-dates-
             | an...
             | 
             | "The present moment used to be the unimaginable future."
             | -Steward Brand
             | 
             | "How can we invest in a future we know is structurally
             | incapable of keeping faith with its past? The digital
             | industries must shift from being the main source of
             | society's ever-shortening attention span to becoming a
             | reliable guarantor of long-term perspective. We'll know
             | that shift has happened when programmers begin to
             | anticipate the Year 10,000 Problem, and assign five digits
             | instead of four to year dates. 01998 they'll write, at
             | first frivolously, then seriously." -Steward Brand
             | 
             | 10,000 Year Clock:
             | 
             | https://longnow.org/clock/
        
               | HackerThemAll wrote:
               | I wonder if somebody offers a therapy for that.
        
           | myrmidon wrote:
           | I do agree with your point but I also think that there is a
           | _lot_ of inertia in the sector (rightfully so!) and it is
           | very difficult for languages to become established if they
           | don 't come with a "unique selling point" of sorts, which to
           | me explains how new popular languages have become rarer.
           | 
           | That selling point, for Lua, is the super easy integration
           | via C-API to me (=> making existing compiled applications
           | scriptable), thanks to uncomplicated build (dependency free,
           | simple), the straightforward C-API and the ease of exposing C
           | "modules" to Lua.
           | 
           | On a sidenote:
           | 
           | Don't you think that Y10k-safe dates are somewhat
           | inconsistent with referencing previous decades _directly_?
           | Those dates are also obnoxious to parse for humans (myself,
           | at least).
        
           | DonHopkins wrote:
           | >C# (01999? though arguably it's just a dialect of Java)
           | 
           | That's like saying Java is a dialect of C++. Java was
           | specifically designed as a "fuck you" to C++, and C# was
           | specifically designed as a "fuck you" to Java.
        
             | kragen wrote:
             | While at a political level that's reasonable, at both the
             | semantic and the syntactic level, the first version of C#
             | was very close to Java, much closer than the first version
             | of Java was to C++. https://learn.microsoft.com/en-
             | us/dotnet/csharp/whats-new/cs... is a very vague overview.
        
         | munificent wrote:
         | It is an interesting observation!
         | 
         | I'm sure there are a few unrelated factors going on to
         | influence that plus some inadvertent cherry-picking. But I do
         | think there is a thing to the observation too.
         | 
         | If I had to make a guess, I'd point to a combination of:
         | 
         | 1. This was right around the time that computers were fast
         | enough to afford the runtime cost of garbage collection while
         | still delivering usable apps. The GC languages before the 90s
         | (Lisp, Scheme, Smalltalk, Self) had reputations for abysmal
         | performance and have largely (but not entirely) died out.
         | 
         | 2. This was also the boom of the Internet and web which shifted
         | a lot of computation to server-side after the PC boom had
         | shifted it client-side. That also enabled somewhat slower
         | languages with GC to thrive because first-mover advantage was
         | more valuable than using your servers efficiently. You could
         | just throw more hardware at it.
         | 
         | 3. That boom also created a huge influx of new developers who
         | picked up whatever language happened to be hot at the time. And
         | once they had, they tended to stick with it. I can't find a
         | good graph of the number of software engineers over time but
         | I'd bet that there's a noticeable uptick around the dotcom
         | boom.
        
           | ecshafer wrote:
           | After mulling it over a bit, plus seeing a few other response
           | (Php, Ruby, etc) I think the internet is the reason.
           | 
           | C, C++, Ada, Basic, Fortran. Those were written assuming they
           | were going to be writing systems code and numerical code.
           | There is then some inertia keeping the most successful ones
           | of from those periods going in their spaces.
           | 
           | Then these new languages with new ideas (GCs, Dynamic Typing,
           | etc) they came out and became successful in the newer Web and
           | Application spaces. Now why they won out and not LISP or
           | SmallTalk or what have you, I am not sure. But my hypothesis
           | is that the web is a big part of it.
        
       | pansa2 wrote:
       | > _work has begun on Lua 5.5_
       | 
       | A beta version is now available:
       | 
       | https://www.lua.org/work/
       | 
       | The main change from 5.4 seems to be the (optional?) removal of
       | global-by-default, instead requiring declarations for global
       | variables.
        
         | strenholme wrote:
         | As it turns out, it's possible with Lua going back to 5.1 to
         | not allow undeclared global variables:
         | 
         | https://www.lua.org/pil/14.2.html
         | 
         | That code looks like this in Lua 5.1:                 function
         | set(name, val)         rawset(_G, name, val or false)       end
         | function exists(name)         if rawget(_G, name) then return
         | true end         return false       end       throwError =
         | {__newindex = function(self,name) error("Unknown global " ..
         | name) end,                     __index = function(self,name)
         | error("Unknown global " .. name) end       }
         | setmetatable(_G,throwError)
         | 
         | Then, to use                 set("a") -- set"a" also works
         | a = 1
        
           | ufo wrote:
           | Naturally, the main catch is that this only detects the
           | violation at run-time. It also won't stop you from
           | accidentally overwriting a global variable that already
           | exists.
        
             | nmz wrote:
             | > It also won't stop you from accidentally overwriting a
             | global variable that already exists.
             | 
             | That's also solvable using metatables.
        
       | azemetre wrote:
       | My only context in using Lua is my neovim configuration, does any
       | know of any good books or tutorials that make something more
       | advance using only lua? Anything of note to consider/read/watch?
        
         | strenholme wrote:
         | Shameless plug time: I have written a public domain book which
         | looks at using Lua (Lua 5.1 but the code works in newer
         | versions as well as Lua 5.1/Luau/LuaJIT) as a text parsing
         | engine. The book assumes familiarity with other common *NIX
         | scripting languages (such as AWK, Perl, or Python) and goes
         | over in detail the pain points for people coming from a *NIX
         | scripting background:
         | 
         | https://maradns.samiam.org/lunacy/SamDiscussesLunacy.pdf
         | 
         | Source files (.odt file, fonts used by book):
         | 
         | https://github.com/samboy/lunacy/tree/master/doc
         | 
         | Hope this helps!
        
           | azemetre wrote:
           | Thanks for recommendation and writing the book! I'm reading
           | the introduction, it doesn't answer why you chose to fork lua
           | and create lunacy. What were you trying to solve with lunacy
           | that lua couldn't do?
           | 
           | The TOC looks great, I will read this soon. Need to finish
           | "Debugging CSS" first (another good book IMO).
        
             | strenholme wrote:
             | The main reason I made Lunacy was to have a standard
             | compile of Lua 5.1, since it's possible to make a Lua 5.1
             | compile with, say 32-bit floats or which only supports
             | integers but not floats.
             | 
             | Lunacy also has a few built in libraries which are not
             | included with Lua 5.1, such as binary bitwise operations
             | (and/or/xor). It also fixes some security issues with Lua
             | 5.1 (better random number generator, hash compression
             | algorithm which is protected from hash flooding attacks).
             | 
             | In addition, I have made a tiny Windows32 binary of Lunacy.
             | 
             | Don't worry about the Lunacy changes; _all_ of the examples
             | in the book work with bog standard Lua 5.1 with a bit32
             | library (bit32 is common enough most OSes with a Lua 5.1
             | package also have a bit32 package for Lua 5.1).
        
         | kevinfiol wrote:
         | Don't have tutorials or books, but I've had a ton of fun using
         | Lua with LOVE2D [0] for gamedev, and also Redbean [1] for
         | building super small portable web applications. Earlier this
         | year, I built a mini CMS [2] inspired by rwtxt with Redbean.
         | 
         | [0] https://love2d.org/
         | 
         | [1] https://redbean.dev
         | 
         | [2] https://github.com/kevinfiol/beancms
        
           | azemetre wrote:
           | Haven't heard of love2d but have heard of pico-8. I've
           | avoided most game dev tutorials because they seem overly
           | focused on beginners, which is fine, but want to find more
           | advance materials that assume the reader knows some basics.
           | 
           | Maybe I should reconsider and dive more into game dev.
        
             | ksymph wrote:
             | This series of tutorials might be of interest:
             | https://github.com/a327ex/blog/issues/30
             | 
             | > It's aimed at programmers who have some experience but
             | are just starting out with game development, or game
             | developers who already have some experience with other
             | languages or frameworks but want to figure out Lua or LOVE
             | better.
             | 
             | Also on the topic of game engines with lua scripting, the
             | wonderful Defold always deserves a mention
             | https://defold.com/
        
         | hmokiguess wrote:
         | Take a look at Roblox, their market cap is almost 100B, they
         | developed Luau and their game engine runs on it.
         | 
         | - https://luau.org/ - https://luau.org/why
        
         | jrop wrote:
         | I always wrote Lua off, scoffing at the 1-based indexing, until
         | I was "forced" to learn it thanks to Neovim. What a delightful
         | little language it is. I do wish I could do certain things less
         | verbosely (lambdas would be nice) -- but then again, I defeat
         | myself by suggesting it, because not having all the features
         | makes Lua so approachable.
        
           | azemetre wrote:
           | Same here, in fact something I wish the neovim team would do
           | is create a book where popular plugin authors create
           | tutorials that recreate basic functionality of their plugins.
           | 
           | Seems like a no brainer that would help bring in more revenue
           | too, it'd also be an "evergreen" book as new others can
           | contribute over time.
           | 
           | I can't be the only one that would immediately buy a copy. :D
        
             | jrop wrote:
             | I'm actually trying to work on a video-series to do just
             | this. I've made my own rudimentary plugins reproducing
             | several popular ones, and would like to walk through how I
             | made: a) file-tree b) picker/fzf replacment c) hop/leap
             | replacement d) surround plugin e) code-formatter f) hydra
             | (sub-modes) g) many "UI" (interactive) buffers, etc.
             | 
             | None of these are published because the popular ones are
             | better and provide more functionality, but I want to share
             | what I believe is more valuable: what I learned while
             | writing them.
        
               | azemetre wrote:
               | That sounds great! Do you have a youtube channel or
               | something to follow when you release it?
        
               | jrop wrote:
               | Yep, though I'm still trying to hit my stride recording
               | videos. I don't release regularly because of lots of
               | amazing $life things.
               | 
               | https://www.youtube.com/@nocturing
               | 
               | If you want a sneak peak of what I want to walk through,
               | check this repo (see the examples/ folder):
               | https://github.com/jrop/u.nvim
        
           | ardit33 wrote:
           | I used Lua professionally. I prefer the 1 indexing... it just
           | feels more natural. For some reason the C apologists here
           | will scream how 0 based is the only way to go. (which is not,
           | it is just a historical artifact). Languages like ADA allowed
           | you to use either 0 or 1, (or any arbitrary) starting index.
        
           | groovy2shoes wrote:
           | Lua has lambdas. They too suffer from verbosity, of course,
           | but they're there.                   function(x) return x;
           | end
        
             | jrop wrote:
             | That's what I meant and didn't communicate well. I'm
             | wishing for short-form syntax of lambdas, to be clear.
        
         | ufo wrote:
         | Definitely include Roberto's Programming in Lua book in your
         | list. Specially if you'd like to script Lua together with C.
         | The book has a good primer on the Lua-C api in its latter half.
        
       | sgt wrote:
       | That's it - I'm building my next startup in Lua!
        
         | jll29 wrote:
         | A useful design pattern is to write highly efficient "engine"
         | code in C/C++ and then tie it together to highly customizable
         | application code with an embedded scripting language.
         | 
         | Lua is great for this, and while you could use a LISP (Emacs,
         | AutoCad) or a FORTH (any real-life example not from the radio
         | telescope domain?) or Tcl/Tk (https://wiki.tcl-
         | lang.org/page/Who+Uses+Tcl), Lua is small (as in number of
         | concepts to understand), easy to read and understand, and
         | compact (as in tiny codebase to integrate, few dependencies).
         | 
         | So many gaming startups have put their money on Lua.
        
           | groovy2shoes wrote:
           | The Lua-C API is also really consistent and straightforward.
           | Bindings can be generated mechanically, of course, but it's
           | really easy to embed by hand, and the documentation is
           | superb.
        
             | sgt wrote:
             | And LLM's should be proficient in Lua and the bindings by
             | now. That will help with velocity.
        
       | alcroito wrote:
       | Anybody knows if there's a lua DAP (debugger) server in
       | development by anyone?
       | 
       | Neovim lua has https://github.com/jbyuki/one-small-step-for-
       | vimkind but it doesn't seem there's any DAP server for regular
       | lua.
        
       | strenholme wrote:
       | Here's my bit of public domain code for iterating through tables
       | in Lua so that the elements are sorted. This routine works like
       | the pairs() function included with Lua:                 -- Like
       | pairs() but sorted       function sPairs(inTable, sFunc)
       | if not sFunc then           sFunc = function(a, b)
       | local ta = type(a)             local tb = type(b)
       | if(ta == tb)               then return a < b              end
       | return ta < tb           end         end         local keyList =
       | {}         local index = 1         for k,_ in pairs(inTable) do
       | table.insert(keyList,k)         end         table.sort(keyList,
       | sFunc)         return function()           key = keyList[index]
       | index = index + 1           return key, inTable[key]         end
       | end
       | 
       | Example usage of the above function:
       | a={z=1,y=2,c=3,w=4}       for k,v in sPairs(a) do
       | print(k,v)       end
       | 
       | With a sort function:                 a={z=1,y=2,c=3,w=4}
       | function revS(a,b)         return a>b       end       for k,v in
       | sPairs(a,revS) do         print(k,v)       end
       | 
       | (Yes, this is a lot easier to do in Perl or Python, since those
       | languages unlike Lua have built in list iterators, but it's
       | possible to do in Lua too)
        
         | nmz wrote:
         | If you did not return a closure, you could set the metatables
         | __pairs to use your function's. Sadly, you could not do this
         | without keeping some sort of cache, which would be a terrible
         | waste of memory, but then again you're already creating an
         | iterator that iterates completely, to me, this beats the use of
         | an iterator (to not iterate over everything and break on a
         | single pass)
        
       | hackthemack wrote:
       | I was thinking a while back, how nice it would be if lua was the
       | scripting language in the browser instead of javascript. There
       | are some projects to compile lua to wasm and have it run in the
       | browser...
       | 
       | https://pluto-lang.org/web/#env=lua%3A5.4.6&code=if%20_PVERS...
       | 
       | But interoperability with the DOM is the missing key.
       | 
       | Still, if lua was used instead of javascript, I could see myself
       | saying... man, I wonder what browser development would be like if
       | we replaced lua with x.
        
         | strenholme wrote:
         | There's also a Javascript implementation of Lua which allows
         | one to run Lua in a browser:
         | 
         | https://github.com/fengari-lua/fengari-web
         | 
         | I don't know if this can access the DOM in Lua, but considering
         | that Fengari is in Javascript, adding a _DOM global variable
         | should not be too hard (if it hasn't already been done).
        
           | bawolff wrote:
           | Fengari lets you access the DOM. Its pretty cool.
        
         | james2doyle wrote:
         | There is also nelua (https://nelua.io/) which can use WASM to
         | compile allow its usage in the browser:
         | https://github.com/edubart/nelua-game2048/
        
         | realharo wrote:
         | What specifically do you think would be better? Lua shares many
         | of JS's quirks (like the relationship between arrays and non-
         | array objects, the behavior of undefined for non-existent
         | object properties, metatables are somewhat similar to JS
         | prototypes, etc.) and adds a bunch more (lack of continue
         | statement, 1-indexing, cannot have nil values in tables).
         | 
         | I can see people liking or disliking Lua and JS _both_ ,
         | depending on taste, but it's hard to see someone liking one and
         | disliking the other.
        
           | TheCycoONE wrote:
           | I held a similar opinion several years ago. The main thing is
           | that lua has less magic than js largely because it's been
           | allowed to break compatibility.
           | 
           | My main example is self in lua which is just the first
           | argument of a function with some syntactic sugar vs this in
           | javascript which especially before 'bind' often tripped
           | people up. The coercion rules are also simpler largely by
           | virtue of making 0 true.
        
           | hackthemack wrote:
           | I agree mostly in that Lua and Javascript are both similar,
           | and like I said in my post above, I could see myself saying
           | the exact opposite if Lua had been included in the browser.
           | 
           | The things I do not like about Javascript can easily be shot
           | down in an argument. Some of it was having to work with
           | Javascript (and it's evil cousin JScript) in the 90s and
           | early 00s.
           | 
           | The type coercion and in the early days people used '=='. I
           | think === did not even appear until ie6?
           | 
           | [] == ![] // true
           | 
           | The lack of a lot of easy helper functions in the standard
           | lib. That now are provided by people writing a bunch of stuff
           | in the npm ecosystem.
           | 
           | The npm ecosystem itself. Lack of security. Lack of...
           | curation? (Also, all this would have probably happened anyway
           | if Lua was in the browser)
           | 
           | I also think javascripts long history has created a legacy of
           | different paradigms
           | 
           | variable declaration var, let, const
           | 
           | function declaration
           | 
           | function f1() {}
           | 
           | const f2 = function() {};
           | 
           | const f3 = () => {};
           | 
           | const obj = { f4() {} };
           | 
           | There is a lot of stuff like this in javascript. I could
           | probably make a blog post about it. But the above gives the
           | general idea of my complaints.
        
             | b_e_n_t_o_n wrote:
             | In practice you don't run into these issues often. I'm
             | annoyed when you see different function declaration
             | conventions in the same codebase, but generally () => is
             | used for either one line functions or inline lambdas, and
             | function foo(){} for everything else. Nobody uses var
             | anymore.
             | 
             | The implicit conversions is a definite footgun tho.
        
               | plopz wrote:
               | Funny you mention nobody uses var anymore when I just saw
               | a post on here yesterday that perf critical code still
               | uses var since it's faster
        
           | thefaux wrote:
           | Lua has tail call optimization and js doesn't. For me, this
           | is a dealbreaker for js.
           | 
           | Lua also has operational advantages compared to javascript.
           | You can build it from source in at most a few seconds and run
           | it anywhere that has a c compiler. The startup time is
           | negligible even compared to a compiled c program so you can
           | run entire scripts that do very useful things faster than
           | most js engines can print hello world. There is also the
           | benefit that in spite of what this article discusses, it is
           | possible for most problems to write a lua solution that works
           | for all lua >= 5.1. This is wonderful because it means if I
           | stick to the standard library, the bitrot is essentially
           | zero.
           | 
           | Calling into c is very straightforward in Lua, especially
           | with luajit, which makes it superior to js as a scripting
           | language (the node ffi api is quite painful in my experience
           | and ffi runs against the js execution model).
           | 
           | Lua also essentially got lexical scoping of local variables
           | correct from the beginning while js blessed us with the
           | nightmare of var.
           | 
           | Of course Lua is far from perfect, but while there are some
           | similarities, the differences are quite significant and
           | meaningful.
        
             | nout wrote:
             | Why is tail call optimization a dealbreaker for you? That's
             | very specific...
        
               | malkia wrote:
               | IMHO, Tail call optimization makes sense only when it's
               | enforced (like in clojure), otherwise it's wild.
        
             | pjmlp wrote:
             | In theory JavaScript also has it on its standard,
             | unfortunately that is yet another thing that browser
             | vendors don't agree on.
        
           | bawolff wrote:
           | I like lua better because its minimalist. Javascript feels
           | like a kitchen sink language.
           | 
           | Otoh, missing ++, +=, ..= operators really bothers me.
           | 
           | But that's just personal taste, not objective by any means.
        
             | hackthemack wrote:
             | Yeah. I think if I were to pick one reason, it would be Lua
             | is "minimalist". But, like I wrote, maybe, it too, would
             | have just had lots of stuff added onto it if it had been in
             | the browser. Hard to say.
             | 
             | I love ++, but you know what? I was shocked when a co-
             | worker pointed out that it is frowned upon to use ++ in
             | javascript. It some big companies, their linter settings
             | mark ++ as something that should be changed.
             | 
             | https://eslint.org/docs/latest/rules/no-plusplus
        
               | bawolff wrote:
               | Lol, i suppose there is no accounting for taste, but the
               | justification for that rule is really something.
               | 
               | Appearently its really confusing if you put a bunch of
               | newlines between the ++ operator and its ophand. No
               | kidding.
        
           | spacechild1 wrote:
           | For me, JS has just too much magic, in particular the
           | behavior of 'this', and lots of weird quirks, like "for in"
           | vs. "for of". Lua, on the contrary, is very predictable and
           | therfore easy to understand.
           | 
           | One killer feature of Lua (that surprisingly few scripting
           | languages have) is stackful coroutines, i.e. you can yield
           | across nested stack frames. Unlike JS or Python, there is no
           | artificial split between generators and async/await and no
           | need for function coloring.
           | 
           | If Lua had zero-based indexing, it would be close to perfect
           | :)
        
             | 112233 wrote:
             | Have you read large Lua codebases written by others? It is
             | write-only language. All your "very predictable" features
             | are overloadable, at runtime. No static typing to rest your
             | eye on. It is a swamp.
             | 
             | "But, just write good code" you will say. Just like with
             | Perl, some languages are designed in a way to discourage
             | writing good code...
        
               | spacechild1 wrote:
               | I'm talking about the core language, which I do find very
               | predictable. You can go crazy with any language. Lua is
               | definitely not worse than Python or JS in this regard.
               | 
               | > No static typing to rest your eye on.
               | 
               | That goes for any dynamically typed language. How is that
               | an argument against Lua in particular?
               | 
               | > Have you read large Lua codebases written by others?
               | 
               | No, because I use it as a scripting language, as
               | intended. I totally agree that one shouldn't use
               | dynamically typed languages for building large
               | applications. But again, this is not specific to Lua.
        
         | pansa2 wrote:
         | IIRC Brendan Eich has talked about this - if he'd adopted Lua
         | in 1995 instead of creating JavaScript, it wouldn't have been
         | Lua 5.x but Lua 2.x.
         | 
         | Lua has improved substantially from version to version because
         | it's been able to break compatibility. That wouldn't be
         | possible in the browser, so today we'd still be stuck using (an
         | augmented version of) the outdated Lua 2.x.
        
       | rebolek wrote:
       | I don't understand why Python is so popular when there's Lua.
       | It's just so much better. Not as good as Rebol but still much
       | better than Python.
        
         | poly2it wrote:
         | Python has a much larger and more mature ecosystem. Lua barely
         | has a functioning package manager.
        
           | ksymph wrote:
           | It's still early in development, but the new package manager
           | Lux looks promising: https://github.com/lumen-oss/lux
        
           | flykespice wrote:
           | Don't forget it's much more productive writing a script in
           | Python to parse a text than Lua due to its huge feature-rich
           | syntax
        
         | karel-3d wrote:
         | Lua is great when you need an embedded language.
         | 
         | That's it. It's not great on its own, in my opinion.
         | 
         | It becomes really gnarly if you have a bigger Lua codebase.
        
         | nmz wrote:
         | Rebol is the cleanest/greatest language I've read code for but
         | the VM is the slowest VM I've ever wrote code for, mind you I
         | only did the first 10 exercises of euler but the only thing
         | that has it beat is writing a shellscript that forks to dc/bc
         | on each math expression.
        
       | sieep wrote:
       | I've been saying it for years: Lua needs its Ruby on Rails moment
        
         | flykespice wrote:
         | Hell no, keep it small as is, no influence from big
         | corporations and no enshittification (or having a "DHH problem"
         | in Lua community)
        
           | sieep wrote:
           | I see your point. I've just craved a rails-like experience in
           | Lua for a while and don't believe there's anything out there
           | yet built on Lua that can match with the big boys (rails,
           | .NET, etc.)
        
         | rodolphoarruda wrote:
         | Yes, with Lapis[1].
         | 
         | [1] https://leafo.net/lapis/
        
           | sieep wrote:
           | Looks promising. Thanks for sharing!
        
       | ST33LDI9ITAL wrote:
       | Don't leave out Fennel! https://fennel-lang.org/
        
       ___________________________________________________________________
       (page generated 2025-10-07 23:01 UTC)