Two Languages Ending in end: The Unexpected Kinship of Eiffel and Lua
Finnian Reilly
Two Languages Ending in end: The Unexpected Kinship of Eiffel and Lua
An essay inspired by this short youtube video: Why learn LUA ?
(Caution: AI generated content, watch out for hallucinations !)
Contents
- Introduction
- Born outside the mainstream, shaped by a single vision
- A family resemblance in syntax
- One concept to rule them all
- Objects as a do-it-yourself kit
- Uniform access, arrived at from opposite ends
- Exceptions without try
- Concurrency without threads and locks
- Both are married to C
- Closures that arrived by different roads
- Where the resemblance ends, and why that matters
- Lua's home in the games industry
- Lua keywords
- Lua Notes
Introduction
On the surface, Eiffel and Lua are about as different as two programming languages can be. Eiffel is a statically typed, compiled, pure object-oriented language built around Design by Contract, with a type system strict enough to prove void safety at compile time. Lua is a dynamically typed scripting language that fits in a few hundred kilobytes and has no classes at all. Eiffel wants you to write specifications. Lua wants to get out of your way. One is associated with banking, aerospace and defence. The other powers game mods, Neovim configurations, and nginx plugins.
Look closer, though, and the two start to look like distant cousins. They share origins, aesthetics, and a set of convictions about what a language should leave out. Those shared convictions are less obvious than their differences, and more interesting.
Full article:
-- SmartDevelopersUseUnderScoresInTheirIdentifiersBecause_it_is_much_easier_to_read (Eiffel = Security by Contract + C Speed)
Finnian Reilly
Ulrich Windl
Ulrich Windl
When I had my first contact with LUA (Not sure where, maybe Adobe Lightroom), I had a look at some language examples and wondered: Why YAL (Yet Another Language)? I could see any killer features, and those programs have bugs, too. 😉
However it seems to be popular for games and plugins.
So I think for any new language there should be a comparison between all the existing languages, pointing out the unique features.
I mean many existing languages have flaws, but sometimes one decides to live with those rather than switching to a new language with an uncertain future.
For LUA the advantage may be a small runtime and concurrency support, but I didn't "dig in myself deeply into LUA".
Kind regards,
Ulrich
18.09.2026 21:31:27 Finnian Reilly <fin...@eiffel-loop.com>:
>
> *Two Languages Ending in end: The Unexpected Kinship of Eiffel and Lua[https://www.eiffel.org/blog/Finnian%20Reilly/2026/09/two-languages-ending-end-unexpected-kinship-eiffel-and-lua]*
>
> An essay inspired by this short youtube video: Why learn LUA ?[https://www.youtube.com/watch?v=I_rzFahRFeE]
>
> (*Caution*: AI generated content, watch out for hallucinations !)
>
>
> *Contents*
>
>
> * Introduction[https://www.eiffel.org/node/511/edit#Introduction]
> * Born outside the mainstream, shaped by a single vision[https://www.eiffel.org/node/511/edit#Born_outside_the_mainstream,_shaped_by_a_single_vision]
> * A family resemblance in syntax[https://www.eiffel.org/node/511/edit#A_family_resemblance_in_syntax]
> * One concept to rule them all[https://www.eiffel.org/node/511/edit#One_concept_to_rule_them_all]
> * Objects as a do-it-yourself kit[https://www.eiffel.org/node/511/edit#Objects_as_a_do-it-yourself_kit]
> * Uniform access, arrived at from opposite ends[https://www.eiffel.org/node/511/edit#Uniform_access,_arrived_at_from_opposite_ends]
> * Exceptions without try[https://www.eiffel.org/node/511/edit#Exceptions_without_try]
> * Concurrency without threads and locks[https://www.eiffel.org/node/511/edit#Concurrency_without_threads_and_locks]
> * Both are married to C[https://www.eiffel.org/node/511/edit#Both_are_married_to_C]
> * Closures that arrived by different roads[https://www.eiffel.org/node/511/edit#Closures_that_arrived_by_different_roads]
> * Where the resemblance ends, and why that matters[https://www.eiffel.org/node/511/edit#Where_the_resemblance_ends,_and_why_that_matters]
> * Lua's home in the games industry[https://www.eiffel.org/node/511/edit#Lua's_home_in_the_games_industry]
> * Lua keywords[https://www.eiffel.org/node/511/edit#Lua_keywords]
> * Lua Notes[https://www.eiffel.org/node/511/edit#Lua_Notes]
>
> *Introduction*
> On the surface, Eiffel and Lua are about as different as two programming languages can be. Eiffel is a statically typed, compiled, pure object-oriented language built around Design by Contract, with a type system strict enough to prove void safety at compile time. Lua is a dynamically typed scripting language that fits in a few hundred kilobytes and has no classes at all. Eiffel wants you to write specifications. Lua wants to get out of your way. One is associated with banking, aerospace and defence. The other powers game mods, Neovim configurations, and nginx plugins.
>
> Look closer, though, and the two start to look like distant cousins. They share origins, aesthetics, and a set of convictions about what a language should leave out. Those shared convictions are less obvious than their differences, and more interesting.
>
> Full article:
>
> https://www.eiffel.org/blog/Finnian%20Reilly/2026/09/two-languages-ending-end-unexpected-kinship-eiffel-and-lua
>
> --
> SmartDevelopersUseUnderScoresInTheirIdentifiersBecause_it_is_much_easier_to_read
> (Eiffel = Security by Contract + C Speed)
>
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/def0f11a-ab99-424e-b56a-90df3656bb1a%40eiffel-loop.com[https://groups.google.com/d/msgid/eiffel-users/def0f11a-ab99-424e-b56a-90df3656bb1a%40eiffel-loop.com?utm_medium=email&utm_source=footer].
Finnian Reilly
Short note: If I activate one of the links I get an "Access denied"...
I cut and paste the contents while eiffel.org was still in edit mode which is why the links did not work.Â
Here is the corrected version.
Contents
- Introduction
- Born outside the mainstream, shaped by a single vision
- A family resemblance in syntax
- One concept to rule them all
- Objects as a do-it-yourself kit
- Uniform access, arrived at from opposite ends
- Exceptions without try
- Concurrency without threads and locks
- Both are married to C
- Closures that arrived by different roads
- Where the resemblance ends, and why that matters
- Lua's home in the games industry
- Lua keywords
- Lua Notes
Finnian Reilly
Hi Ulrich,
I think the answer to "why YAL?" is that Lua was never trying to compete with general-purpose languages, so comparing its syntax against theirs misses where its strength lies. IÂ watched this video by a developer called David Hockley, who used Lua as the glue between the user interface and the C++ engine of the city-builder game Cities XL, and he makes the point well: Lua was designed as an extension language, not a standalone one. It's implemented as a small C library (the full reference interpreter compiles to roughly 250 KB), so it's portable, fast, and easy to embed inside a host application. The killer feature is embeddability rather than any particular language construct. That's why you ran into it in Lightroom, and why it turns up in Roblox, World of Warcraft, the Solar2D game engine, Redis (for running logic inside the database) and Neovim (for configuring the editor).
On the "uncertain future" worry, Lua isn't really new. It dates from 1993 (from PUC-Rio in Brazil), which makes it older than Java or JavaScript, and it has a long track record in exactly this embedded niche.
As a language, its appeal is simplicity with a
surprising amount of flexibility. It has only about 21 or 22
keywords (depending on version) and a single data structure, the
table, which serves as array, hash map, set and namespace. There
are no built-in classes or inheritance, but you can build them
yourself using "metatables," which let you override how a value
behaves: what happens when a table is called like a function (__call),
how fields are read and written (__index, __newindex),
how tables are added or compared (__add, __eq),
and so on. David describes this as almost being able to program
the behaviour of the language itself, which makes it easy to
learn but harder to master.
On concurrency, Lua has coroutines, which are cooperative, not parallel threads. So it's good for things like game scripting and state machines, but it doesn't offer true multi-core concurrency out of the box.
The video is also honest about the weaknesses. You can't build a complete application in Lua alone, since the heavy lifting (rendering, for example) is done in the host language, and outside game development there are few jobs that require it. So you're right that there's little reason to switch to Lua as a primary language. It makes sense when an application you use already offers Lua bindings and you want to extend it, or when you want a lightweight way to make your own C/C++ program scriptable.
Above all else, proponents of Lua say it's a very enjoyable/fun language to work with. To me it is the ideal beginners language, and would be a good stepping stone to learning Eiffel.
Kind regards,
Finnian
Finnian Reilly
> As a language, Lua's appeal is simplicity with a surprising amount of
> version) and a single data structure, the table, which serves as
> array, hash map, set and namespace.
similar universal structure. Might be useful for beginners to the language.
Ulrich Windl
I think it's all about comfort: Even if you have a basic language with few keywords that allows you to build your own "syntactic sugar", most will still prefer languages that ship with a lot of such sugar. Maybe a bit like PHP (I never wrote a program) that seems to have a solution for about anything built in (or loadable as extension). Recently they found some security issues there. Maybe that's an argument for having a lean language with some basic well-designed base and reliable library.
I always liked PostScript: You feel that the guys designing the language were absolute experts on graphics, and since "level 3" you can do about anything in 2D. However I'd wish I were a better mathematician, so I could use the tensor field based shfill to my real-wirld problems (I only used triangulation)...
Maybe a language really becomes popular once you provide many tools written in that language, and the users start to wish to "hack" those utilities (thus having to learn that language). Maybe that's true for C and UNIX.
Regards,
Ulrich
rfo amalasoft.com
- Demonstrate the value of Eiffel by creating value with Eiffel
- Instead of trying to convert 1_000 programmers to Eiffel,
- Make Eiffel smaller
- Become the tool of choice for creating tiny apps
- Make Eiffel for Apps freely available (not GPL)
- Make Eiffel bigger
- Build the next generation of frameworks with Eiffel
- Make Eiffel-quality applications possible without having to write them in Eiffel (unless you want to)
- Let Eiffel do the programming
- Let Eiffel do the orchestration
Sent: Saturday, September 19, 2026 12:13 PM
To: eiffel...@googlegroups.com <eiffel...@googlegroups.com>
Subject: Re: [eiffel-users] Two Languages Ending in end: The Unexpected Kinship of Eiffel and Lua
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Finnian Reilly
Hi Roger,
Thanks for digging that out. It holds up remarkably well fifteen years on.
Your point about providing value to 1_000_000 users rather than converting 1_000 programmers resonates. I'd push the number further, to 1_000_000_000 users. That's less fanciful than it sounds, since the eXpat XML parser is present on at least that many devices.
As you may have read, Anders Persson and I are building a drop-in replacement for libexpat (Xpact) written in Eiffel, using the Python community's wrapper as the gateway. The pitch is that it's both more secure and faster than the C original. It follows the current trend of rewriting critical C infrastructure in Rust, but with Design by Contract finding errors that Rust might miss.
It also ticks another box on your slide: "Make Eiffel-quality applications possible without having to write them in Eiffel." A Python developer using it never needs to know there's Eiffel underneath.
I'll be announcing the fifth milestone on this project shortly.
Regards,
Finnian
rfo amalasoft.com
Sent: Saturday, September 19, 2026 3:22 PM
To: eiffel...@googlegroups.com <eiffel...@googlegroups.com>
Subject: Re: [eiffel-users] Two Languages Ending in end: The Unexpected Kinship of Eiffel and Lua
Hi Roger,
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Ulrich Windl
Recently I had been thinking about the project, and I came to the conclusion that an XML parser library is nice, but it's still rather "low level". Wouldn't an efficient implementation of a user tool like "xsltproc" (XML transformation using XSL) have a greater impact? Of course such tool needs an XML parser.
Ulrich
Finnian Reilly
Thanks for thinking about the Xpact project. You're right that an XSLT
processor is closer to end users, and it would need a parser underneath
it, which is partly why I started where I did.
The goal of Xpact (which depends on Xpact-core) is specific: a drop-in,
behaviorally identical replacement for libexpat. Expat is embedded in
Python, Firefox and a long list of other software, so that's where the
reach is. Everyone using those gets the benefit without needing to know
Eiffel exists. That's the core of the "billion-user project" argument.
An xsltproc equivalent would serve a much smaller audience. It's also a
considerably bigger undertaking (XPath, the full XSLT spec, extension
functions), and it only makes sense on top of a parser that has already
proven itself.
For a sense of where things stand: Xpact-core currently shows zero
divergence from expat across more than 186,000 real-world XML files and
900+ office document packages, verified CRC tracking across nearly all
of the callback streams, and it runs about 1.23x faster on average. DTD
and parameter-entity handling and namespace parsing are substantially
complete. It has been effectively a full-time effort to get here.
As for transformation itself, I've never felt much need for XSLT and
don't like the verbosity of XML syntax as a declarative language. In
Eiffel-Loop I use a combination of Evolicity, a small templating
language, and a high-level Eiffel interface to VTD-XML. It covers the
same ground, and it has the advantage that any part of a transformation
too awkward to express declaratively can simply be written in Eiffel. So
XSLT isn't something I plan to pursue. But if someone wanted to build an
XSLT processor on top of Xpact, the parser would be there for them, and
I'd be happy to answer any questions about the API.
Best,
Finnian
> Hi!
>
> Recently I had been thinking about the project, and I came to the conclusion that an XML parser library is nice, but it's still rather "low level". Wouldn't an efficient implementation of a user tool like "xsltproc" (XML transformation using XSL) have a greater impact? Of course such tool needs an XML parser.
>
> Ulrich
Ulrich Windl
I'm also no big fan of XSL, but you can do cool things, e.g. in a web browse: Export some database table into XML and provide an XSLT to build a fancy HTML page from it. So you can separate data from appearance.
XSL needs editor support to be bearable: auto-indent and auto-completion, as well as real-time validation. Emacs can do it all (with syntax highlighting.
I also used Perl's XML::Twig (https://metacpan.org/pod/XML::Twig) to manipulate XML; for example remove sll xml comments for poor applications that clai to parse xml, but chokzon comments....
Regards,
Ulrich
Finnian Reilly
> XSL needs editor support to be bearable: auto-indent and auto-complet
don't have to read the code, only look at the result.