Years ago, I tried lua and wasn't impressed. Then I started using Neovim, did the necessary configuration in lua, but continued writing my own scripts in vimscript. Later I started using wezterm and decided to give lua a second shot, and I began to really like it.
I realized my initial dislike for lua stemmed from my experience with javascript (back in the jwquery days), where maintaining large codebases felt like navigating a minefield. The lack of type system made it all too easy to introduce bugs.
But lua isn't like that.
It's not weakly typed like javascript - it's more akin to pythons dynamic duck typing system. Its simplicity makes it remarkably easy to write clean maintainable code.
Type checking with type is straightforward compared to python, mostly because there are only five basic types (technically seven but I've never used userdata or thread).
And I even started to enjoy using metatables once I understood how and when to apply them.
That being said, lua's lack of popularity probably stems from its limited stdlib, which often feels incomplete, and the absence of a robust package manager.
luarocks is a pain to work with.
All that being said, I don't really see the point of using this project.
While I do wish type annotations were a native feature, the ones provided by the lsp are good enough for me.
BTW, you might want to check Lux [1], it's a new approach for Lua packaging. They launched it recently, so there's a lot of work going on. But it looks and feels very promising
> That being said, lua's lack of popularity probably stems from its limited stdlib, which often feels incomplete, and the absence of a robust package manager. luarocks is a pain to work with.
And indexing arrays starting from 1 rather than 0.
It doesn't "index arrays from 1", it doesn't have arrays, but tables, that can operate as "sequences". It's all documented in the docs.
>>> A table with exactly one border is called a sequence. For instance, the table {10, 20, 30, 40, 50} is a sequence, as it has only one border (5). The table {10, 20, 30, nil, 50} has two borders (3 and 5), and therefore it is not a sequence. (The nil at index 4 is called a hole.) The table {nil, 20, 30, nil, nil, 60, nil} has three borders (0, 3, and 6) and three holes (at indices 1, 4, and 5), so it is not a sequence, too. The table {} is a sequence with border 0. Note that non-natural keys do not interfere with whether a table is a sequence
> But lua isn't like that. It's not weakly typed like javascript - it's more akin to pythons dynamic duck typing system
What? No, Lua's type system is practically identical to JavaScript's.
Even metatables are extraordinarily similar to prototype chains via __index (though much more powerful since they allow for operator overloading, which I wish JS had).
> Its simplicity makes it remarkably easy to write clean maintainable code.
Not based on my experience with even just medium-sized lua codebases. Anything over a few thousand lines and in continuous development has been a mess. Not lua's fault per se¹ but the only thing in my experience that compares is what you'd see in pre-laravel php. Every significant codebase is a messy ad hoc one-off framework in its own right.
A lot of people, as always when it comes up, are speaking of their recreational, small-project or config system lua code. Which is fine, it's good for that. But I have a lot of professional experience working in live production lua codebases and my experiences with it are different over there.
¹ A lot of large lua projects started as someone's first lua project or maybe even first code project at all, which is a tremendous accomplishment for a language but not a smooth ride for maintainers taking over those projects.
I was expecting Teal to be "Lua + type annotations", similar to Mypy. However from a quick look it does indeed seem to be a "dialect" in its own right. Teal is Lua-like and compiles to Lua, but there's more to it than just static types. Perhaps it's more similar to TypeScript?
For example, Teal replaces Lua's tables - the language's signature single, highly-flexible data structure - with separate arrays, tuples, maps, records and interfaces. It changes the variable scoping rules and even adds macro expressions.
Teal therefore seems substantially more complex than Lua. The author recognizes this in the conclusion to a recent presentation [0]: Lua is "small and simple", maybe Teal is "something else"? Lua is for "scripting", maybe Teal is better suited to "applications/libraries"?
It's interesting that you mention Typescript. In Typescript's early history, they added a bunch of features that they either thought would make it nicer for C# devs (classes, enums, option chaining, decorators, namespaces, etc.). Eventually, a bunch of these features were added to Javascript natively in nearly the exact same way they were implemented in Typescript. Now, the only remaining non-type-related features not added to Javascript are enums and namespaces, which will never be added because they're poorly designed. Even the Typescript type syntax (but with ignored semantics) may get added to Javascript under a WIP proposal. Some of these features were perhaps mistakes -- private in TS and private in JS will never be able to mean the same thing, and `class` syntax is iffy -- but overall there was an improvement.
By ambitiously adding useful features, could Teal push the upstream to make progress? Probably not because Lua's scope is intended to be small (and we're no longer in the same context as 2015 era Typescript and tc39), but it's interesting to think about.
Minor nitpick: decorators are still in "stage 3". Not formally part of ECMAScript standard yet.[1]
Anyway, that has not stopped large parts of the JavaScript ecosystem -- notably Angular -- from using an experimental variant of decorators, such as the one provided by TypeScript. [2]
I feel conflicted about decorators, which I’ve only used in the context of nestjs.
They’re undeniably productive, but they’re very black box-ish. Just slap a decorator on a method, now it’s a cron job! Slap a decorator on, and now you’re logging the function call!
I feel like a lot of problems that decorators solve could also be solved with good ol’ higher order functions. Decorators also give zero (or limited? Idk) information to the typescript compiler, so you end up asserting a lot of types instead of inferring them.
I have all these gripes, but it really is amazing to throw decorators on stuff and have it work. Especially with third party libraries that provide decorators. I gave a nestjs app a queueing system by installing bullmq, then just slapping the bullmq decorators around!
Makes me think of the Rich Hickey “simple made easy” talk. Decorators are definitely not simple, which makes me naturally dislike them. But damn are they easy!!
> I feel like a lot of problems that decorators solve could also be solved with good ol’ higher order functions.
The Stage 3 version of decorators are mostly just a syntax sugar for higher-order function composition. (As opposed to the rejected at Stage 1 version that did a lot more "reflection" and type meta-magic.) I personally was rooting for the Pipeline composition operator to win out first over decorators as what I feel a more generally useful higher-order function composition tool, but I understand given Java/C#/Python how much more people seem to love the decorator syntax.
Even worse a lot of Angular ecosystem still relies a lot on a previous Decorators proposal that was withdrawn at Stage 1. If you are still using the `experimentalDecorators` flag in your build you aren't using the Stage 3 version of Decorators (which don't have a build flag, just a target requirement).
Enums are possibly going to end up in JS eventually - this proposal[0] is at stage 1 (i know the readme says stage 0, it looks like there is a PR to update this). Granted, that means 'under consideration' but it is a start
Just a small note about mypy and python - annotations are first-class citizens in Python3 and are not tied to any particular type checking system such as mypy, but are instead a core part of the language and actually serve vital functions in frameworks and libraries that are used to check interfaces such as Pydantic and FastAPI (eg URL params).
Mypy is just one type checker for Python, but there are many others including pyright. In fact pyright is quickly becoming the dominant checker over mypy.
Am I right in thinking that Python's type annotation syntax originally came from Mypy though?
IIRC Mypy started off as a type annotation syntax and corresponding type checker for Python. Mypy's type annotations were adopted by Python itself (in version 3.5 - PEP 484), which reduced Mypy's role to be just a type checker.
Since then, type annotations have indeed become a core part of Python - not only are they used in frameworks and libraries, but are also required to use language features like @dataclass.
No, Python's current type annotation syntax was added in Python 3.0 as a generic annotation syntax, in the hope that somebody else might come along and build a type-checker or other tooling on top:
MyPy was one such tool, and I think it had conventions for adding type annotations in comments, in places where Python didn't yet support them (such as variable assignment), but I'm pretty sure it was never a TypeScript-style pre-processor - type-annotated programs always ran directly in the unmodified CPython interpreter.
That was a major concern when I was using Lua at work. Pretty much every type checker in Lua required transpiling, which doesn't work for many environments (e.g. Redis script). My Kailua [1] was designed that in mind but didn't reach its full potential.
> Teal replaces Lua's tables - the language's signature single, highly-flexible data structure - with separate arrays, tuples, maps, records and interfaces
They're all just Lua tables with specialized type checking for specific behavior.
I really wish the Lua authors would add official types to Lua. The time has come.
> I really wish the Lua authors would add official types to Lua.
Never going to happen IMO. Adding static types would change the nature of the language completely, even more than it has in Python.
As Teal shows, it would require giving up one of Lua's core features: tables as the language's single data structure. It would significantly complicate a language known for its simplicity.
Even the implementation would need to change radically - adding a type checker would invalidate the current approach of using a single-pass source-to-bytecode compiler.
>> I really wish the Lua authors would add official types to Lua.
> Never going to happen IMO. Adding static types would change the nature of the language completely, even more than it has in Python.
You both are kind of right.
The Lua authors have been working on the new companion language to Lua named Pallene. Pallene is a subset of Lua that adds types, not for the sake of types themselves, but for the purpose of performance. The Pallene compiler can generate optimized native code that potentially removes the need to manually write a module for Lua in C.
The other cool trick is that Pallene and Lua are completely interoperable with each other, so Pallene can be added to existing Lua projects, and you can opt to use regular Lua for the dynamic parts of your code where compilers won't be able to optimize much and strong types might be more trouble than help.
Well that's kinda disappointing. I expected something more in 2025, like directly generating asm like a lot of languages are starting to do.
And your article makes it ambiguous whether it's from the Lua authors or grad students. I assume it started out just the students and then the Lua authors joined in?
One of Lua's goals has been extreme portability, and the main implementation works on anything that has a C compiler, going to the extreme of compiling cleanly on C89, C99, and even compiling as C++ (no extern "C"). Remember that Lua is popular in the embedded space too, so this is a big feature.
Pallene isn't designed to be a new native language on its own. Pallene is designed to be a companion language for Lua, specializing in a subset of performance.
But as importantly, Pallene isn't just compiling to C. Pallene is generating C code that directly manipulates the underlying Lua internals, which are in C.
The research thesis is that many bottlenecks are due to boxing and unboxing going through an FFI. Memory safety also incurs overhead. Python is an extreme example of how excruciatingly slow this can be, but even Lua incurs costs for this. A core tenant of the Pallene compiler is that it can generate C code that gets to cheat like crazy. Pallene gets to directly access Lua internals and things like arrays directly manipulate underlying C arrays deep inside, which sidesteps boxing/unboxing. The compiler can do the analysis to make sure it doesn't cheat in a way that is unsafe. Finally, the C optimizer now also has a chance to perform optimizations. And now operations such as crunching math on arrays of numbers may get much faster because now you get generated code that is more CPU friendly and may benefit more from prefetching and cache locality.
Pallene is built from the the extreme compatibility goals as Lua since it is designed to work with it. It it only depends on any C compiler and Lua itself. If you get Lua compiled, then you can get Pallene working. That means any existing project that uses Lua (5.4) could start adding Pallene modules to their project for new features or to try to improve performance in key areas. Since Pallene just outputs a Lua modules, it looks like any other Lua module implemented in C, so it won't create new portability constraints that you didn't have before. This is different than say LuaJIT, where not all platforms may allow JIT or you may be targeting a new CPU architecture that LuaJIT does not support.
Both Teal and Pallene were started by grad students of Roberto's. Since Roberto has started giving talks himself on Pallene, I'm assuming they are joining in.
I'm Pallene's lead maintainer. Currently the code is maintained by me, my students and other open sou rce collaborators. We collaborate with Roberto over some Pallene-related research, specially about the type system semantics, but he isn't an active committer.
If it goes further and generates native C control flow statements when possible ("if", "for", native functions, native function calls, etc), I think it could be an omni-level language, generating basically Lua statements when dynamic and C when not, and mixing them all within the same program, entirely controlled by how much type information you give it (and how you use tables and metatables).
Alas, as of last month we changed Pallene's compiler and it now generates C gotos for control flow. ( ^ _ ^ メ ) It helped with certain optimizations...
In reality, tables are used in specific fashions and not fully generally. (Partly because Lua itself even recognizes some of these fashions and provides relevant operations accordingly.) Lua tables are not really a single data structure; it is a single type that acts as multiple data structures at once.
Yeah Lua optimizes array tables for performance as long as they're arrays. That's the only optimization I'm aware of. I get why they didn't just add arrays, to keep the syntax and semantics clean, simple, and unambiguous. I just don't like it. If you take that to its extreme, you get Lisp. Natural human languages are messy and full of warts, but they work despite that, or perhaps because of that, because human life is messy and warty. "Pure" languages never can or do catch on. My favorite language right now is unironically TypeScript despite all its baggage.
More than just keeping it simple, it's also about reducing the API surface of the language. Lua's main design constraint is that it's meant to be embedded inside other applications, and the versatile table type helps a lot in that regard.
You can't have typed tables without giving up tables as the language's single data structure. You would have tables and typed tables which are essentially just arrays with extra steps.
Not with type erasure like TypeScript does. Then it would just be type checking hints as to how the table is used, not a different kind of table. Teal does this.
Teal still compiles all those things into plain Lua tables, it's just that the type system has different table subtypes for better type checking. I think the variable scoping is also the same as regular Lua?
> It aims to fill a niche similar to that of TypeScript in the JavaScript world, but adhering to Lua's spirit of minimalism, portability and embeddability.
I mean that's exactly what the page says, doesn't it?
> It aims to fill a niche similar to that of TypeScript in the JavaScript world, but adhering to Lua's spirit of minimalism, portability and embeddability.
After having embedded Lua in my game engine and having worked with some Lua games I've come to conclusion that:
- Lua is great from the integrator/engine dev perspective. It's easy to embed and there are several libraries that help with creating bindings between Lua and your game classes.
- Lua has absolutely terrible runtime performance especially when the GC stalls. You soon learn that you have to start moving code to the native side and carefully consider the APIs that you provide for the game so that you can even dream of any type of performance. Haven't tried LuaJIT since that doesn't work with WASM so it's not an option for me.
- The loose runtime typing in Lua is absolutely terrible, and while it's easy and fast to knock up some simple script you really pay the price when you try to maintain or refactor your code and you have no typing information. For the game engine developer this also makes it very hard to provide any kind of help for the game developer, i.e. "intellisense" kind of functionality. I've basically "solved" this by assuming that variables have certain name suffixes and prefixes and when those are present I assume that it has a certain type which lets me provide a list of functions in the script editor to the game developer. Far from perfect. [see link below]
The lua language service [1] supports type annotations inside comments [2]. Sure, it is not the same as having types as first class citizens, but I would say that it solves 95% of the editor support and typying problems you mentioned in your 3rd point.
But yeah, PUC-Rio Lua is not fast, but it is acceptable, and maybe one of the most performant of all non-JIT dynamic languages. If you need speed, JIT is a requirement.
I've been diving into Lua (a little late to this party, but turns out it's a perfect language to rewrite some commandline scripts I had that were getting unwieldy in Bash, especially with LLM assistance!) and it's really something of an eye-opener.
LuaJITted Lua code runs at 80% (on average, sometimes faster!) of the compiled C version of the same algorithm, typically. Lua is embedded in a surprisingly massive number of products: https://en.wikipedia.org/wiki/List_of_applications_using_Lua The startup time of a script is in nanoseconds. An "echo" written in Lua runs faster than the native echo implementation.
The only warts so far are 1-based indexing (you get used to it), and the fact that LuaJIT is stuck at Lua 5.1 while Lua itself is up to 5.3 or 5.4 and has added some niceties... with Lua proper running slower. And no real standard library to speak of (although some would argue that's a feature; there are a few options and different flavors out there if that's what you need, though- Such as functional-flavored ones...)
Anyway, there's nothing else like it out there. Especially with its relative simplicity.
There are also some neat languages that compile to (transpile to?) Lua, and deserve more attention, such as YueScript https://yuescript.org/, which is a still actively-updated enhanced dialect of MoonScript https://moonscript.org/ (described as "Coffeescript for Lua", although it hasn't been updated in 10 years) although neither of these are typed. HOWEVER... there IS this: TypescriptToLua https://typescripttolua.github.io/, which takes advantage of ALL the existing TypeScript tooling, it just outputs Lua instead of JS!
> LuaJITted Lua code runs at 80% (on average, sometimes faster!) of the compiled C version of the same algorithm, typically
Cannot confirm this. It might be true on selected micro benchmarks. Here are the results of the Are-we-fast-yet benchmark suite, which includes a decent set of benchmarks challenging CPU, cache and memory access: https://github.com/rochus-keller/Oberon/blob/master/testcase....
On average, the C and C++ implementations are five times faster than LuaJIT.
> There are also some neat languages that compile to (transpile to?) Lua
Have a look at the results and the code; there are benchmarks in the suite where the (ideomatic) C/C++ implementation is "only" twice as fast as the corresponding (idiomatic) Lua implementation, but on average (geomean of all factors) it's about five times as fast. The guidelines of the benchmark are pretty strict to enable fair comparisons (see https://github.com/smarr/are-we-fast-yet/blob/master/docs/gu...).
I looked at the docs. This seems to be comparing against Lua, which is why I specifically said LuaJIT
This is quite a distinction to be made. Can you clarify?
Directly from their guidelines page:
Lua
We write code compatible with Lua 5.1, 5.2 and 5.3.
Smalltalk/Ruby symbols are represented as normal strings.
We use Lua 1-based array and the length operator #.
We use single object when a class is not required.
Bitwise operators with various Lua versions is a nightmare.
We use luacheck as a linter.
If they are writing code compatible with Lua 5.2 or 5.3, then that cannot be LuaJIT, which is ONLY compatible with Lua 5.1. (Unless they mean that they JUST write 5.1 code, which due to backwards compatibility is runnable on 5.2 and 5.3? It's unclear from here.)
It is true that LuaJIT is stuck at 5.1, but you could write any performance critical sections in C/C++ and call it from Lua.
Lack of LuaJIT for 5.1+ isn't that big of a deal for desktop apps. The embedded world is still stuck in 5.1, but for them, the benefits of the latest Lua is marginal.
And despite it being stuck at 5.1, it still implements features from other versions. For example, there is the "LJ_52" macro, so you can compile "table.pack" and "table.unpack" into LuaJIT, which I do, because I use both at times.
There is also the compat53 library which polyfills most of the missing parts. The Teal compiler has --gen-target and --gen-compat flags which adapts the generated Lua code for different Lua versions, and allows using the compat53 library behind the scenes if desired, so you can get a mostly Lua-5.3+ experience over LuaJIT using Teal.
I haven’t found many downsides yet. I was already starting to rewrite some things in Awk (which I was drawn to for similar reasons- fast script startup time, simple easy language with good defaults), but Awk (while still also awesome) isn’t really designed for stuff beyond a certain size (no signal handling unless you use a fork, for example)
LuaJIT is missing bignums, ints that aren’t floats, bit operations, and native utf8 handling, but it can pretty easily be extended with libraries, ffi and metatabling. (I actually made a working bignum library that integrates with gmp, but it has a memory leak somewhere and it’s a rabbit hole/bikeshedding project at this point…)
LLM assistance helps hugely and I really like YueScript’s syntax additions. You can point any LLM at a syntax describing webpage and it will pretty much write that language for you…
I do think you're better off using ruby, but if you insist.
Lots of default functionality missing so you MUST have these packages: inspect, luaposix, lrexlib-pcre, lrexlib-posix, lpeg, luastd/stdlib, luasocket, luahttp, luasec, luacheck, penlight
* luajit is unnecessary in almost all cases, you don't need the speed.
* use lsp or luacheck whenever you write something, entr -c luacheck file on everything.
* patterns are not regex which means they do not support lookups, backtracking or |, so you must install lrexlib-pcre or lrexlib-posix (frankly I never need pcre so I stick to lrexlib-gnu or lrexlib-posix).
* overload _ENV so it auto requires unknown things, I have a lua wrapper that does this and it makes it a joy not having all of my scripts with a bunch of require"posix" on all of them
* install inspect to inspect tables
* os.execute and io.popen only accepts strings as parameters which means you should overload it and make a function that accepts tables as well.
* 5.4 is still lacking support for many libraries, 5.3 has most of the libraries.
* assignments default to the global environment so you have to use local keyword or set _ENV to error on assignment (or better yet, don't care, just local _ENV = mymodule)
Overall, Lua is just a mixture of C with a pascal syntax and garbage collection (and also tables which is a weird data structure)
Another one of the biggest uses of Lua outside the hyperscaler-type software like nginx or redis: Roblox. Soooo many kids run games on Roblox every day!
Roblox not only runs entirely on Lua, but they've been working on their own type inference version of Lua named Luau, and open sourced it, and it's still in very active development.
I'm so relieved to see more types being added to good languages.
So Teal is to Lua as TypeScript is to JavaScript. Which means it automatically plays well with any Lua environment. Unlike luau and nelua which are also statically typed but have their own runtimes.
What version of Lua does it use? Lua gets new versions every few years so I don't know why so many impls don't continuously upgrade to the latest version.
> The core compiler has no dependencies and is implemented as a single tl.lua file which you can load into your projects. Running tl.loader() will add Teal support to your package loader, meaning that require() will be able to run .tl files.
It's nothing like C, and that's so much of its charm.
Semantically, Lua is almost identical to the core of JavaScript. Metatables are a genius alternative to prototype chains.
Lua's syntax is beautifully simple and unambiguous, but at the cost of being moderately inconvenient in 2025 unfortunately. It could benefit from an ESNext-style renewal.
I get why they made the C API that way, but in practice it's very easy to get wrong.
I'm not sure how fast vanilla Lua is today compared to similar languages. I think LuaJIT (and Luau?) are most often used when performance is needed.
Sure, if you compare via semantics Lua and Javascript make sense to liken. But in terms of complexity, Lua is far more like C. There's no unfucking all the horrible decisions baked into javascript and I wouldn't touch it with a ninety-foot pole, but Lua still has some hope.
To be fair Lua also made some bad decisions, though maybe not as bad as javascript:
- tables being used for both objects and arrays can create a lot of confusion, especially when you have some integer keys, but not all, and especially when they are not consecutive or one of them is 0
- indexes start at 1
- assigning nil deinitializes variables/entries instead of assigning the value `nil` (this becomes especially bad if you mistakingly try to use nil as a value in an array/table)
- nil and false are falsy, but not 0, which instead is truthy
No disagreement here; I also fundamentally question the cardinal indexing and conflation between table and array. But it's at least internally consistent and certainly makes more sense than mandatorily indexing arrays with floating point.
Like another commenter said, using . instead of : is maybe the most common mistake, too easy to make. And Lua offers no help preventing or checking it.
TypeScript is a great language. So is Lua. So is C.
When used carefully to avoid their warts. Learning how to do that for any language takes time and practice though.
Yea, and then there's javascript (or typescript if you prefer), the C++ of scripting languages. It's sometimes difficult to see any value through the warts. (Unless you're paid to, of course.)
Having a favorite language is weird (to me). They're tools, and some are more effective and usable than others, and some are better suited to some tasks than others.
But, equivalently, of course I'm going to criticize a hammer if it's literally covered in warts making it difficult to grasp without slipping. (or, if the gun I'm trying to use keeps firing bullets into my foot when I'm aiming down range.)
FYI, for those who may not be aware, moonscript is the "coffeescript" for lua. It has been in production use for quite a while (the author of moonscript also created itch.io, using ... moonscript).
yuescript, from the dora-ssr game engine dev, is essentially moonscript-2.0
And of course, if you want to treat lua as the scheme-like it really is (deep down), then ... fennel.
Lots of choices. They all compile to straightforward lua, are very easy to incorporate (you can even compile at runtime, if you wish), and all employ full lua semantics, meaning zero runtime overhead
EDIT: and the curse of not reading fully ahead strikes again (doh!). Someone else has made the same points below ...
If Teal is the TypeScript of Lua, Fennel is the ClojureScript. Except Fennel is fully implemented in Lua itself and it transpiles (usually) to very simple, plain Lua code without much (if any) overhead and with no run-time library other than what is in Lua itself.
I don't think it's a good language, and I hate it. I've made thousands of the same mistakes with it—typing . instead of :. There's a reason Lua has a smaller audience than assembly.
> There's a reason Lua has a smaller audience than assembly.
I don't think that's true. It's a very embedded language. Its use in video games and video game modding alone would outnumber the number of people directly writing assembly to achieve things.
It's also a very old embeddable language, which is probably most of why it's so often chosen for that purpose. Many similar languages have been written from scratch inspired by Lua over the last 10-15 years, some of them almost definitely better than Lua in many respects, but they get no traction because Lua has all the steam. Unfortunate, because the authors of Lua are fairly happy with semantic and syntactic decisions that many of us are very unhappy with.
Not moving straight to a more recent version, but still cherry-picking some parts of them. You can see some functionalities from Lua 5.2 and 5.3 are working in Luajit: https://luajit.org/extensions.html
Teal currenly supports generating code for Lua 5.1 and up, including LuaJIT. There are compiler flags --gen-target and --gen-compat which control various specifics of code generation.
Off-topic comment, but as an ESL speaker I just this week randomly learned that teal the color is named after the duck species Anas crecca, called (edit: common or Eurasian) teal in English.
TIL! My wife is a photographer and she's been photographing a ton of Blue-winged Teals over the last couple months during their migration. I assumed that the ducks had been named after the color.
Cool! (Just to be clear, I meant the common, or Eurasian, teal whose iridescent green head markings the color’s apparently named after. The NA teals are closely related, although it seems they were assigned to their own genus in 2009 as it was discovered that the then-Anas was not monophyletic.)
Generally colors are named after things in nature and not the other way around, given that the latter would’be had names for a long time, and most color names are comparatively recent inventions, driven by modern dyes and pigments and status, fashion, etc concerns. A West European peasant in the 11th century would’ve known the bird well, possibly trapped them for food, but would’ve had very little need for a separate word for ”blue-green”.
The history of color words is quite interesting. There’s a specific progression that almost all languages have gone through. It’s fairly well known that many East Asian languages don’t have separate names for ”blue” and ”green” at all (except as modern loans). Accordingly, they don’t usually make the distinction mentally, one could think that they simply consider them hues of ”cyan”.
About blue and green, I know absolutely nothing about this, but I was randomly Wikipedia-surfing a few days ago and found the long page on this topic that is interesting (but has the scary warning at the top about multiple issues).
And though they mention it as being for third party libraries, this also seems a way to declare types for your own code in an external file, thus keeping your code as runnable Lua and benefiting from type checking too. That seems like a neat workflow for developing Neovim plugins with this: instead of having to constantly regenerate Lua from .tl files so Neovim can pick up your changes during development.
> this also seems a way to declare types for your own code in an external file, thus keeping your code as runnable Lua and benefiting from type checking too
The declaration file isn't used to typecheck the code the declaration is for. It is only for consumers of the code.
I really want to like Lua but I just can’t. Tried Lua/Fennel/even Teal but I just can’t.
I can’t tell what it is exactly. Maybe those weird global rules? Maybe inspection of objects and metatables? Maybe the weird mix of verbose and not verbose (e.g. getting output of a process requiring popen and manual handling but then function can take more arguments than declared and whateva) or exotic control flow and structures (metatable, global env).
It’s interesting language, but I just grit my teeth every time I’m interacting with it.
Has anyone used this? Any reviews? Based on the Github issues, the type system seems to have some holes in it, but it's not obvious how bad is it in real world.
I used it to write a couple Pico-8 games a year or two ago since Lua + dynamic typing is a major obstacle for me managing game code over time. Teal worked well for that.
This is super cool. I have been using TypeScript To Lua (https://github.com/TypeScriptToLua/TypeScriptToLua) for a little game side project and it works quite well, I am pleased with it. It does end up generating a lot of Lua code though because it has to support all of TypeScript’s features, which isn’t ideal. I’d expect Teal’s output to be much more concise Lua which has me interested.
Teal's output is currently pretty much 1-to-1 with the input apart from removing all of the type information of course. (I've been trying hard to keep it that way so that the error messages in stack traces match the input lines without having to do source mapping.)
I really love teal! Here is a 10k loc project I have in it - https://github.com/Koeng101/libB/blob/dev/src/dnadesign/dnad... - Basically, I reimplemented all my synthetic biology bioinformatics from Go into teal so that LLMs can script with it better in a hermetic environment. It's got all sorts of things like cloning simulation, codon optimization, genbank parsing, synthesis fixing, reliable sequence hashing, sequence analysis, etc. I'm pretty sure it is a more complete synbio library than anything in python, actually.
A couple things I want from teal:
1. I wish there was a better way to bundle files together. I have a little build.lua, but eh, I think it could be better. I know of cyan and everything but I feel like that was developed for a different application than mine. I want to have 1 complete file that I can just give people and allow them to do synbio work in any target language with a lua machine.
2. There are some annoyances around luajit vs lua5.1 functionality
3. The compiler yelling at you gets old for integrating raw lua. I tried to port json.lua in and even with the definition file, I couldn't embed the whole json.lua without having compiler errors. So eventually I just imported it as a string that is type checked, which is bad
4. I really wish syntax highlighting on github was a thing
The good bits:
It's pretty much complete. I used it a couple years ago and there were things with generics that I just couldn't do, but now it is much better. For example, how I use generics for the different parsers (fastq, fasta, genbank, slow5, pileup, etc) https://github.com/Koeng101/libB/blob/dev/src/dnadesign/src/...
Overall, love it! It is one of those pieces of software which is nearly complete, and I love using software like that.
Teal creator here! Thank you for the kind words, super happy to see people being productive with it!!
On your wishlist items:
1. There are a few third-party projects that bundle Lua code. One that comes to mind is https://lrocket.codeberg.page/ — I don't know if this functionality should be brought into Teal itself, it sounds to me like something better left to the surrounding tooling?
2. Unfortunately those annoyances are part of the heterogeinity of the Lua ecosystem, but Teal tries to paper over them using the compat53 library (which, granted, is not available everywhere if you want to do a pure-Lua deployment on existing Lua environments). The --gen-target and --gen-compat flags should still help some, hopefully!
3. Not sure what you mean there -- you mean adding chunks of untyped Lua _in the same file_? I think that if you have a json.lua and a json.d.tl file, then it should use the definition file only and leave the .lua file alone. At least that's the intended behavior!
4. That's up to GitHub :) Last time I checked their docs I think they want something like 100 or 200 projects using the language for considering adding native highlighting for it on the website. But you can add a .gitattributes file to the root of your repository like this https://github.com/teal-language/tl/blob/master/.gitattribut... and at least it will display .tl files with .lua highlighting.
1. Yeah, there are third party bundlers, but none of em worked too well for me. You are right: it should be separate
2. If I recall correctly, gen-target didn't hit it because I was using some very esoteric bullshit from the luajit internal spec that couldn't have nice typing
3. Yes, untyped lua in the same file. The problem is that I want everything in a single file for distribution and embedding - kind of like the SQLite amalgamation. It'd be super cool to just add in my dnadesign.lua or dnadesign.tl file and have full bioinformatics in almost any language! Definition files don't work as well there - I still kind of use them for the type definitions, but then embed the raw file as a string
4. YES THANK YOU! I'm not sure if it is in the docs but this is SO useful!
I really like Lua and I work with it almost daily.
But, I hate luarocks. It just don't work well on Windows. And I don't know why. The management of external libraries makes Lua still too difficult to use, which is a real shame considering the qualities of this programming language.
Something to keep an eye out for is Lux: https://github.com/nvim-neorocks/lux. Looks like a promising replacement to Luarocks, but is still pretty early in development.
How does it disambiguate it? Are single-element tuples just never used in practice? To be fair, maybe the only time I've had to use them in TypeScript is via Parameters<T>
In our experience, single-element tuples are just never used in practice. There has been some discussion on how to add syntax for them, but I think it's more of a desire for orthogonality than for a practical need.
I tried it for one project, but converted it to TypeScript-to-Lua instead.
I used Lua on the backend and my frontend was already in TypeScript, so it was nice that I could reuse the backend types without conversion in the frontend.
This is very cool. I wonder if it works with Roblox, which is probably the environment with the largest number of Lua programmers. It certainly looks like it should work basically anywhere Lua works.
> Luau, stuck on 5.1 (correct me if I am wrong) like LuaJit for performance reasons.
It's not just for performance reasons, and they don't exactly have no features from newer versions. Take a look at the compatibility tables: https://luau.org/compatibility
> How confident are you in the soundness of the type system?
I am confident it is not sound! That is by design. A typical example is how function arguments are bivariant, to allow for callbacks expressed the way programmers usually expect them to work (TypeScript does something similar).
> Also, are there any Lua constructs that are difficult/impossible to type?
Yes, many of them. The type system and the compiler are pragmatically very simple -- there are many design decisions made to favor simplicity of specification and/or implementation. (Compare the single-file, single-pass Teal compiler done mostly by a single person with the amount of engineering resources that Microsoft has put into TypeScript.) For a concrete example, we have special-cased polymorphism for functions, intended to use with very dynamically-typed Lua functions from the broader Lua ecosystem, but you cannot express similar polymorphism in Teal itself.
> Is type checking decidable? (Is the type system Turing complete?)
There is a proof (which I can't find right now) that type checking is not decidable once you combine parametric polymorphism (generics) and intersection types (like the poly functions I mentioned above), but the forms of these features supported by Teal have some restrictions which make me not extend such claims directly. And of course, I can't even claim that the implementation of the theoretical model is bug-free. The model is evolving, the implementation always lags a bit behind.
In any case, the goal for Teal's type system is not academic purity, but pragmatic utility. Other comments in this thread alluded to this as well -- there are practical constraints that come from targeting an existing language and ecosystem. Of course, there are many ways one can approach such challanges. Teal is one of them and there were and are certainly others! Everyone is free to take their shot at where they want to be in the Unix-Philosophy/Worse-is-Better vs. Lisp-Philosophy/The-Right-Thing design gradient.
Thanks for the detailed answer! I just wish the website was more upfront about this. I cannot find anything about "soundness" on the front page or in the docs.
I think you could basically copy your comment into an FAQ section or something on the front page.
People get this way about TypeScript too, and it always perplexes me. These projects are about adding types to untyped languages, and that comes with a few givens:
* Your type system cannot be sound. It's going to have escape hatches and exceptions because that's how dynamic languages roll.
* There will always be constructs that you can't type. See above.
* If your type system is going to usefully type enough of the ecosystem, it will be Turing complete.
All of these things are the trade-offs you make when you set out to layer types on a dynamic language, and they're well worth it to get 99% of the way to type safety in a language that otherwise couldn't scale. Theoretical purity is meaningless if the language isn't useful.
This one I disagree with. Type assertions with runtime checks could keep the typed fragments sound, unlike TypeScript and Python. Also see Elixir's strong arrow proposal for how to encode which assertions can be elided on function calls (because the function will assert them already).
A tricky tradeoff is that, because Teal compiles to Lua source, adding those run-time type checks would incur some considerable overhead. I've seen other languages in this space easily run 2 or 3 times slower when run-time checks are turned on. It's an open research problem.
You might be interested in checking out Pallene. Like Teal it's also Lua with types but it does check types at run-time, in an efficient way. However, Pallene's type system is currently not as featureful and production ready as Teal.
TypeScript supports runtime type assertions, but it doesn't mandate them or write them for you.
I should have said your type system cannot be sound without runtime overhead. And I don't believe that choosing automatic runtime overhead is the right move.
The problem is not that it doesn't write them for you, but that `as MyType` is way too ergonomic of a syntax for unchecked assertions, whereas checked assertions require effectively parsing the structure manually with typeof checks.
TypeScript desperately needs a way to derive type-guarding functions from types (and so does every gradually-typed language). There're libraries for this but you need to define the types themselves through combinators.
> Your type system cannot be sound. It's going to have escape hatches and exceptions because that's how dynamic languages roll.
I think you could prove that you can't construct a sound & complete type system for Lua. But just saying "Your type system cannot be sound" by itself is definitely wrong. I don't understand why people are throwing out both soundness & completeness, instead of at least retaining one (and I think the choice here is pretty obvious, a sound but incomplete type system is much more useful than an unsound one).
From Flow's website[1] (a type checker for JavaScript):
> Flow tries to be as sound and complete as possible. But because JavaScript was not designed around a type system, Flow sometimes has to make a tradeoff. When this happens Flow tends to favor soundness over completeness, ensuring that code doesn't have any bugs.
I don't understand why other type systems for dynamically typed languages cannot strive for that, and in particular I am pretty salty at TypeScript for explicitly not caring about soundness.
Why, though? Completeness matters more than soundness in practice for this kind of language, which is a large part of what gave TypeScript its edge. The only people who complain about soundness seem to be those whose approach to TypeScript is one of theoretical interests rather than practical application.
> How confident are you in the soundness of the type system?
Teal's types are hints, like Python's and TypeScript's, so I suspect it's not sound by design.
> Also, are there any Lua constructs that are difficult/impossible to type?
Teal includes several types that model typical uses of Lua tables, e.g. as arrays, maps etc. It doesn't look like it can type fully general use of Lua tables, e.g. using both the "array part" and "hash part" of the same table.
I designed and named the Transaction Execution Approval Language for the Algorand blockchain in 2020. I'm partial to the original, but as it grew it got rebranded to be the "Algorand Virtual Machine". Glad someone still remembers it as TEAL!
I think you and GP both mean that this TEAL is adjacent to crptocurrency, and therefore, who cares about stepping on toes?
This heuristic works well in most cases maybe, but will lead to false positives sometimes. May I gently suggest that this might be one of those cases. Algorand is the project of this fellow
Credentials aren't faultless but they do provide a certain web of trust. If you browse the academic and professional history of this fellow, I think you'll agree.
Algorand is, I think, as serious and sincere a research project as any other.
I meant that I have a sort of affection for Lua, so it gets preferential treatment in my book, and therefore Teal ought to get the name above another relatively random project with the same name.
Oof. What is it about the devs who prefer static typing that they insist on bolting it onto every scripting language they can? It's nearly a compulsive disorder.
There's plenty of languages with compile time type safety, just go use one of them and leave the perfectly good dynamic ones alone.
Static typing proponents need accept that dynamic typing is a perfectly valid way to write and run code: It's way less verbose, it focuses code on logic rather than syntax (a.k.a. "scripting"), it's easier to mentally parse and generally easier to both learn and use.
Inflicting types on every piece of code written is just ridiculous.
Because when your project reaches the 10k lines mark, you want something telling you "Woops, that function you declared only accepts numbers as the first parameter" and there's nothing preventing lua to have minimal compile time safety while also being backward compatible in fact, I think one of the lua transpilers allowed for function (n number, s string, a) (a is any type here)
Years ago, I tried lua and wasn't impressed. Then I started using Neovim, did the necessary configuration in lua, but continued writing my own scripts in vimscript. Later I started using wezterm and decided to give lua a second shot, and I began to really like it.
I realized my initial dislike for lua stemmed from my experience with javascript (back in the jwquery days), where maintaining large codebases felt like navigating a minefield. The lack of type system made it all too easy to introduce bugs.
But lua isn't like that. It's not weakly typed like javascript - it's more akin to pythons dynamic duck typing system. Its simplicity makes it remarkably easy to write clean maintainable code. Type checking with type is straightforward compared to python, mostly because there are only five basic types (technically seven but I've never used userdata or thread). And I even started to enjoy using metatables once I understood how and when to apply them.
That being said, lua's lack of popularity probably stems from its limited stdlib, which often feels incomplete, and the absence of a robust package manager. luarocks is a pain to work with.
All that being said, I don't really see the point of using this project.
While I do wish type annotations were a native feature, the ones provided by the lsp are good enough for me.
BTW, you might want to check Lux [1], it's a new approach for Lua packaging. They launched it recently, so there's a lot of work going on. But it looks and feels very promising
[1]: https://github.com/nvim-neorocks/lux
> That being said, lua's lack of popularity probably stems from its limited stdlib, which often feels incomplete, and the absence of a robust package manager. luarocks is a pain to work with.
And indexing arrays starting from 1 rather than 0.
It doesn't "index arrays from 1", it doesn't have arrays, but tables, that can operate as "sequences". It's all documented in the docs.
>>> A table with exactly one border is called a sequence. For instance, the table {10, 20, 30, 40, 50} is a sequence, as it has only one border (5). The table {10, 20, 30, nil, 50} has two borders (3 and 5), and therefore it is not a sequence. (The nil at index 4 is called a hole.) The table {nil, 20, 30, nil, nil, 60, nil} has three borders (0, 3, and 6) and three holes (at indices 1, 4, and 5), so it is not a sequence, too. The table {} is a sequence with border 0. Note that non-natural keys do not interfere with whether a table is a sequence
> But lua isn't like that. It's not weakly typed like javascript - it's more akin to pythons dynamic duck typing system
What? No, Lua's type system is practically identical to JavaScript's.
Even metatables are extraordinarily similar to prototype chains via __index (though much more powerful since they allow for operator overloading, which I wish JS had).
> Its simplicity makes it remarkably easy to write clean maintainable code.
Not based on my experience with even just medium-sized lua codebases. Anything over a few thousand lines and in continuous development has been a mess. Not lua's fault per se¹ but the only thing in my experience that compares is what you'd see in pre-laravel php. Every significant codebase is a messy ad hoc one-off framework in its own right.
A lot of people, as always when it comes up, are speaking of their recreational, small-project or config system lua code. Which is fine, it's good for that. But I have a lot of professional experience working in live production lua codebases and my experiences with it are different over there.
¹ A lot of large lua projects started as someone's first lua project or maybe even first code project at all, which is a tremendous accomplishment for a language but not a smooth ride for maintainers taking over those projects.
> Teal is a statically-typed dialect of Lua.
I was expecting Teal to be "Lua + type annotations", similar to Mypy. However from a quick look it does indeed seem to be a "dialect" in its own right. Teal is Lua-like and compiles to Lua, but there's more to it than just static types. Perhaps it's more similar to TypeScript?
For example, Teal replaces Lua's tables - the language's signature single, highly-flexible data structure - with separate arrays, tuples, maps, records and interfaces. It changes the variable scoping rules and even adds macro expressions.
Teal therefore seems substantially more complex than Lua. The author recognizes this in the conclusion to a recent presentation [0]: Lua is "small and simple", maybe Teal is "something else"? Lua is for "scripting", maybe Teal is better suited to "applications/libraries"?
[0] https://youtu.be/Uq_8bckDxaU?t=1618
It's interesting that you mention Typescript. In Typescript's early history, they added a bunch of features that they either thought would make it nicer for C# devs (classes, enums, option chaining, decorators, namespaces, etc.). Eventually, a bunch of these features were added to Javascript natively in nearly the exact same way they were implemented in Typescript. Now, the only remaining non-type-related features not added to Javascript are enums and namespaces, which will never be added because they're poorly designed. Even the Typescript type syntax (but with ignored semantics) may get added to Javascript under a WIP proposal. Some of these features were perhaps mistakes -- private in TS and private in JS will never be able to mean the same thing, and `class` syntax is iffy -- but overall there was an improvement.
By ambitiously adding useful features, could Teal push the upstream to make progress? Probably not because Lua's scope is intended to be small (and we're no longer in the same context as 2015 era Typescript and tc39), but it's interesting to think about.
Minor nitpick: decorators are still in "stage 3". Not formally part of ECMAScript standard yet.[1]
Anyway, that has not stopped large parts of the JavaScript ecosystem -- notably Angular -- from using an experimental variant of decorators, such as the one provided by TypeScript. [2]
[1] https://github.com/tc39/proposal-decorators
[2] https://github.com/angular/angular/issues/48096
I feel conflicted about decorators, which I’ve only used in the context of nestjs.
They’re undeniably productive, but they’re very black box-ish. Just slap a decorator on a method, now it’s a cron job! Slap a decorator on, and now you’re logging the function call!
I feel like a lot of problems that decorators solve could also be solved with good ol’ higher order functions. Decorators also give zero (or limited? Idk) information to the typescript compiler, so you end up asserting a lot of types instead of inferring them.
I have all these gripes, but it really is amazing to throw decorators on stuff and have it work. Especially with third party libraries that provide decorators. I gave a nestjs app a queueing system by installing bullmq, then just slapping the bullmq decorators around!
Makes me think of the Rich Hickey “simple made easy” talk. Decorators are definitely not simple, which makes me naturally dislike them. But damn are they easy!!
> I feel like a lot of problems that decorators solve could also be solved with good ol’ higher order functions.
The Stage 3 version of decorators are mostly just a syntax sugar for higher-order function composition. (As opposed to the rejected at Stage 1 version that did a lot more "reflection" and type meta-magic.) I personally was rooting for the Pipeline composition operator to win out first over decorators as what I feel a more generally useful higher-order function composition tool, but I understand given Java/C#/Python how much more people seem to love the decorator syntax.
Even worse a lot of Angular ecosystem still relies a lot on a previous Decorators proposal that was withdrawn at Stage 1. If you are still using the `experimentalDecorators` flag in your build you aren't using the Stage 3 version of Decorators (which don't have a build flag, just a target requirement).
Enums are possibly going to end up in JS eventually - this proposal[0] is at stage 1 (i know the readme says stage 0, it looks like there is a PR to update this). Granted, that means 'under consideration' but it is a start
[0]: https://github.com/tc39/proposal-enum
Just a small note about mypy and python - annotations are first-class citizens in Python3 and are not tied to any particular type checking system such as mypy, but are instead a core part of the language and actually serve vital functions in frameworks and libraries that are used to check interfaces such as Pydantic and FastAPI (eg URL params).
Mypy is just one type checker for Python, but there are many others including pyright. In fact pyright is quickly becoming the dominant checker over mypy.
Am I right in thinking that Python's type annotation syntax originally came from Mypy though?
IIRC Mypy started off as a type annotation syntax and corresponding type checker for Python. Mypy's type annotations were adopted by Python itself (in version 3.5 - PEP 484), which reduced Mypy's role to be just a type checker.
Since then, type annotations have indeed become a core part of Python - not only are they used in frameworks and libraries, but are also required to use language features like @dataclass.
No, Python's current type annotation syntax was added in Python 3.0 as a generic annotation syntax, in the hope that somebody else might come along and build a type-checker or other tooling on top:
https://peps.python.org/pep-3107/
MyPy was one such tool, and I think it had conventions for adding type annotations in comments, in places where Python didn't yet support them (such as variable assignment), but I'm pretty sure it was never a TypeScript-style pre-processor - type-annotated programs always ran directly in the unmodified CPython interpreter.
That was a major concern when I was using Lua at work. Pretty much every type checker in Lua required transpiling, which doesn't work for many environments (e.g. Redis script). My Kailua [1] was designed that in mind but didn't reach its full potential.
[1] https://github.com/devcat-studio/kailua/
> Teal replaces Lua's tables - the language's signature single, highly-flexible data structure - with separate arrays, tuples, maps, records and interfaces
They're all just Lua tables with specialized type checking for specific behavior.
I really wish the Lua authors would add official types to Lua. The time has come.
> I really wish the Lua authors would add official types to Lua.
Never going to happen IMO. Adding static types would change the nature of the language completely, even more than it has in Python.
As Teal shows, it would require giving up one of Lua's core features: tables as the language's single data structure. It would significantly complicate a language known for its simplicity.
Even the implementation would need to change radically - adding a type checker would invalidate the current approach of using a single-pass source-to-bytecode compiler.
>> I really wish the Lua authors would add official types to Lua.
> Never going to happen IMO. Adding static types would change the nature of the language completely, even more than it has in Python.
You both are kind of right.
The Lua authors have been working on the new companion language to Lua named Pallene. Pallene is a subset of Lua that adds types, not for the sake of types themselves, but for the purpose of performance. The Pallene compiler can generate optimized native code that potentially removes the need to manually write a module for Lua in C.
The other cool trick is that Pallene and Lua are completely interoperable with each other, so Pallene can be added to existing Lua projects, and you can opt to use regular Lua for the dynamic parts of your code where compilers won't be able to optimize much and strong types might be more trouble than help.
Here is a talk Roberto Ierusalimschy gave about Pallene. https://www.youtube.com/watch?v=pGF2UFG7n6Y
Docs https://github.com/pallene-lang/pallene/blob/master/doc/manu...
Looks similar to Teal.
This is relatively exciting.
Also, called it!
Disappointed that it maintains syntactic Lua compatibility. Would have been a good time for a clean slate on the shoulders of hindsight.
> Looks similar to Teal.
That's because they share a common origin from Typed Lua and Titan languages:
https://teal-language.org/book/other_projects.html
Wait, Pallene just compiles to C using whatever local C compiler?
https://github.com/pallene-lang/pallene/blob/master/src/pall...
Well that's kinda disappointing. I expected something more in 2025, like directly generating asm like a lot of languages are starting to do.
And your article makes it ambiguous whether it's from the Lua authors or grad students. I assume it started out just the students and then the Lua authors joined in?
One of Lua's goals has been extreme portability, and the main implementation works on anything that has a C compiler, going to the extreme of compiling cleanly on C89, C99, and even compiling as C++ (no extern "C"). Remember that Lua is popular in the embedded space too, so this is a big feature.
Pallene isn't designed to be a new native language on its own. Pallene is designed to be a companion language for Lua, specializing in a subset of performance.
But as importantly, Pallene isn't just compiling to C. Pallene is generating C code that directly manipulates the underlying Lua internals, which are in C.
The research thesis is that many bottlenecks are due to boxing and unboxing going through an FFI. Memory safety also incurs overhead. Python is an extreme example of how excruciatingly slow this can be, but even Lua incurs costs for this. A core tenant of the Pallene compiler is that it can generate C code that gets to cheat like crazy. Pallene gets to directly access Lua internals and things like arrays directly manipulate underlying C arrays deep inside, which sidesteps boxing/unboxing. The compiler can do the analysis to make sure it doesn't cheat in a way that is unsafe. Finally, the C optimizer now also has a chance to perform optimizations. And now operations such as crunching math on arrays of numbers may get much faster because now you get generated code that is more CPU friendly and may benefit more from prefetching and cache locality.
Pallene is built from the the extreme compatibility goals as Lua since it is designed to work with it. It it only depends on any C compiler and Lua itself. If you get Lua compiled, then you can get Pallene working. That means any existing project that uses Lua (5.4) could start adding Pallene modules to their project for new features or to try to improve performance in key areas. Since Pallene just outputs a Lua modules, it looks like any other Lua module implemented in C, so it won't create new portability constraints that you didn't have before. This is different than say LuaJIT, where not all platforms may allow JIT or you may be targeting a new CPU architecture that LuaJIT does not support.
Both Teal and Pallene were started by grad students of Roberto's. Since Roberto has started giving talks himself on Pallene, I'm assuming they are joining in.
I'm Pallene's lead maintainer. Currently the code is maintained by me, my students and other open sou rce collaborators. We collaborate with Roberto over some Pallene-related research, specially about the type system semantics, but he isn't an active committer.
That's really exciting work. Great job. Hope it's fulfilling.
That's actually really exciting in that case.
If it goes further and generates native C control flow statements when possible ("if", "for", native functions, native function calls, etc), I think it could be an omni-level language, generating basically Lua statements when dynamic and C when not, and mixing them all within the same program, entirely controlled by how much type information you give it (and how you use tables and metatables).
Alas, as of last month we changed Pallene's compiler and it now generates C gotos for control flow. ( ^ _ ^ メ ) It helped with certain optimizations...
Ha! Called it again!
But why gotos instead of proper control flow? Is it just easier to emit?
In reality, tables are used in specific fashions and not fully generally. (Partly because Lua itself even recognizes some of these fashions and provides relevant operations accordingly.) Lua tables are not really a single data structure; it is a single type that acts as multiple data structures at once.
Yeah Lua optimizes array tables for performance as long as they're arrays. That's the only optimization I'm aware of. I get why they didn't just add arrays, to keep the syntax and semantics clean, simple, and unambiguous. I just don't like it. If you take that to its extreme, you get Lisp. Natural human languages are messy and full of warts, but they work despite that, or perhaps because of that, because human life is messy and warty. "Pure" languages never can or do catch on. My favorite language right now is unironically TypeScript despite all its baggage.
More than just keeping it simple, it's also about reducing the API surface of the language. Lua's main design constraint is that it's meant to be embedded inside other applications, and the versatile table type helps a lot in that regard.
> As Teal shows, [official typed Lua] would require giving up one of Lua's core features: tables as the language's single data structure.
Is that true ... you can't have typed tables without giving up tables as a data structure?
You can't have typed tables without giving up tables as the language's single data structure. You would have tables and typed tables which are essentially just arrays with extra steps.
Not with type erasure like TypeScript does. Then it would just be type checking hints as to how the table is used, not a different kind of table. Teal does this.
I'm not sure if I follow.
Teal still compiles all those things into plain Lua tables, it's just that the type system has different table subtypes for better type checking. I think the variable scoping is also the same as regular Lua?
> Perhaps it's more similar to TypeScript?
Funny you should mention that:
> It aims to fill a niche similar to that of TypeScript in the JavaScript world, but adhering to Lua's spirit of minimalism, portability and embeddability.
You can get pretty far by bolting annotations onto Lua (no compilation step), for example using my IDE:
https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis
Admittedly, I've been focused on some other things recently, but still with some focus on type safety e.g. https://breaka.club/blog/godots-most-powerful-scripting-lang...
> Perhaps it's more similar to TypeScript?
I mean that's exactly what the page says, doesn't it?
> It aims to fill a niche similar to that of TypeScript in the JavaScript world, but adhering to Lua's spirit of minimalism, portability and embeddability.
After having embedded Lua in my game engine and having worked with some Lua games I've come to conclusion that:
- Lua is great from the integrator/engine dev perspective. It's easy to embed and there are several libraries that help with creating bindings between Lua and your game classes.
- Lua has absolutely terrible runtime performance especially when the GC stalls. You soon learn that you have to start moving code to the native side and carefully consider the APIs that you provide for the game so that you can even dream of any type of performance. Haven't tried LuaJIT since that doesn't work with WASM so it's not an option for me.
- The loose runtime typing in Lua is absolutely terrible, and while it's easy and fast to knock up some simple script you really pay the price when you try to maintain or refactor your code and you have no typing information. For the game engine developer this also makes it very hard to provide any kind of help for the game developer, i.e. "intellisense" kind of functionality. I've basically "solved" this by assuming that variables have certain name suffixes and prefixes and when those are present I assume that it has a certain type which lets me provide a list of functions in the script editor to the game developer. Far from perfect. [see link below]
https://github.com/ensisoft/detonator/blob/master/screens/ed...
The lua language service [1] supports type annotations inside comments [2]. Sure, it is not the same as having types as first class citizens, but I would say that it solves 95% of the editor support and typying problems you mentioned in your 3rd point.
But yeah, PUC-Rio Lua is not fast, but it is acceptable, and maybe one of the most performant of all non-JIT dynamic languages. If you need speed, JIT is a requirement.
[1]: https://luals.github.io/
[2]: https://luals.github.io/wiki/annotations/
It's a shame you can't use LuaJIT. It's one of if not THE highest performance JIT out there.
Any alternatives you've tried that are better in those areas?
I've been diving into Lua (a little late to this party, but turns out it's a perfect language to rewrite some commandline scripts I had that were getting unwieldy in Bash, especially with LLM assistance!) and it's really something of an eye-opener.
LuaJITted Lua code runs at 80% (on average, sometimes faster!) of the compiled C version of the same algorithm, typically. Lua is embedded in a surprisingly massive number of products: https://en.wikipedia.org/wiki/List_of_applications_using_Lua The startup time of a script is in nanoseconds. An "echo" written in Lua runs faster than the native echo implementation.
The only warts so far are 1-based indexing (you get used to it), and the fact that LuaJIT is stuck at Lua 5.1 while Lua itself is up to 5.3 or 5.4 and has added some niceties... with Lua proper running slower. And no real standard library to speak of (although some would argue that's a feature; there are a few options and different flavors out there if that's what you need, though- Such as functional-flavored ones...)
Anyway, there's nothing else like it out there. Especially with its relative simplicity.
There are also some neat languages that compile to (transpile to?) Lua, and deserve more attention, such as YueScript https://yuescript.org/, which is a still actively-updated enhanced dialect of MoonScript https://moonscript.org/ (described as "Coffeescript for Lua", although it hasn't been updated in 10 years) although neither of these are typed. HOWEVER... there IS this: TypescriptToLua https://typescripttolua.github.io/, which takes advantage of ALL the existing TypeScript tooling, it just outputs Lua instead of JS!
> LuaJITted Lua code runs at 80% (on average, sometimes faster!) of the compiled C version of the same algorithm, typically
Cannot confirm this. It might be true on selected micro benchmarks. Here are the results of the Are-we-fast-yet benchmark suite, which includes a decent set of benchmarks challenging CPU, cache and memory access: https://github.com/rochus-keller/Oberon/blob/master/testcase....
On average, the C and C++ implementations are five times faster than LuaJIT.
> There are also some neat languages that compile to (transpile to?) Lua
Here is a comprehensive list: https://github.com/hengestone/lua-languages. Lanuages like Oberon or Luon directly compile to LuaJIT bytecode (i.e. not to Lua).
The code in Are-we-fast-yet has been heavily optimized. It might still be true that naive LuaJIT can run almost as fast as Naive C.
Have a look at the results and the code; there are benchmarks in the suite where the (ideomatic) C/C++ implementation is "only" twice as fast as the corresponding (idiomatic) Lua implementation, but on average (geomean of all factors) it's about five times as fast. The guidelines of the benchmark are pretty strict to enable fair comparisons (see https://github.com/smarr/are-we-fast-yet/blob/master/docs/gu...).
I looked at the docs. This seems to be comparing against Lua, which is why I specifically said LuaJIT
This is quite a distinction to be made. Can you clarify?
Directly from their guidelines page:
If they are writing code compatible with Lua 5.2 or 5.3, then that cannot be LuaJIT, which is ONLY compatible with Lua 5.1. (Unless they mean that they JUST write 5.1 code, which due to backwards compatibility is runnable on 5.2 and 5.3? It's unclear from here.)It's essentially written in Lua 5.1 with specific alternative implementations of mandelbrot and hashindextable for Lua 5.3 selectable by the test runner. But this doesn't matter much because my reference is LuaJIT. I have also compared different LuaJIT and also PUC Lua implementations, see http://software.rochus-keller.ch/are-we-fast-yet_LuaJIT_2017... and http://software.rochus-keller.ch/are-we-fast-yet_Lua_results....
This actually gave me an idea that I'm going to build out
It is true that LuaJIT is stuck at 5.1, but you could write any performance critical sections in C/C++ and call it from Lua.
Lack of LuaJIT for 5.1+ isn't that big of a deal for desktop apps. The embedded world is still stuck in 5.1, but for them, the benefits of the latest Lua is marginal.
And despite it being stuck at 5.1, it still implements features from other versions. For example, there is the "LJ_52" macro, so you can compile "table.pack" and "table.unpack" into LuaJIT, which I do, because I use both at times.
As someone else have pointed it out, they are cherry picked: https://luajit.org/extensions.html.
There is also the compat53 library which polyfills most of the missing parts. The Teal compiler has --gen-target and --gen-compat flags which adapts the generated Lua code for different Lua versions, and allows using the compat53 library behind the scenes if desired, so you can get a mostly Lua-5.3+ experience over LuaJIT using Teal.
and if you use luajit ffi, those calls actually get called just as fast as from a c program
Any recommendations going from bash to lua to watch out for except indexing?
I haven’t found many downsides yet. I was already starting to rewrite some things in Awk (which I was drawn to for similar reasons- fast script startup time, simple easy language with good defaults), but Awk (while still also awesome) isn’t really designed for stuff beyond a certain size (no signal handling unless you use a fork, for example)
LuaJIT is missing bignums, ints that aren’t floats, bit operations, and native utf8 handling, but it can pretty easily be extended with libraries, ffi and metatabling. (I actually made a working bignum library that integrates with gmp, but it has a memory leak somewhere and it’s a rabbit hole/bikeshedding project at this point…)
LLM assistance helps hugely and I really like YueScript’s syntax additions. You can point any LLM at a syntax describing webpage and it will pretty much write that language for you…
I do think you're better off using ruby, but if you insist.
Lots of default functionality missing so you MUST have these packages: inspect, luaposix, lrexlib-pcre, lrexlib-posix, lpeg, luastd/stdlib, luasocket, luahttp, luasec, luacheck, penlight
* luajit is unnecessary in almost all cases, you don't need the speed.
* use lsp or luacheck whenever you write something, entr -c luacheck file on everything.
* patterns are not regex which means they do not support lookups, backtracking or |, so you must install lrexlib-pcre or lrexlib-posix (frankly I never need pcre so I stick to lrexlib-gnu or lrexlib-posix).
* overload _ENV so it auto requires unknown things, I have a lua wrapper that does this and it makes it a joy not having all of my scripts with a bunch of require"posix" on all of them
* install inspect to inspect tables
* os.execute and io.popen only accepts strings as parameters which means you should overload it and make a function that accepts tables as well.
* 5.4 is still lacking support for many libraries, 5.3 has most of the libraries.
* assignments default to the global environment so you have to use local keyword or set _ENV to error on assignment (or better yet, don't care, just local _ENV = mymodule)
Overall, Lua is just a mixture of C with a pascal syntax and garbage collection (and also tables which is a weird data structure)
Another one of the biggest uses of Lua outside the hyperscaler-type software like nginx or redis: Roblox. Soooo many kids run games on Roblox every day!
Roblox not only runs entirely on Lua, but they've been working on their own type inference version of Lua named Luau, and open sourced it, and it's still in very active development.
https://github.com/luau-lang/luau
I'm so relieved to see more types being added to good languages.
So Teal is to Lua as TypeScript is to JavaScript. Which means it automatically plays well with any Lua environment. Unlike luau and nelua which are also statically typed but have their own runtimes.
What version of Lua does it use? Lua gets new versions every few years so I don't know why so many impls don't continuously upgrade to the latest version.
> The core compiler has no dependencies and is implemented as a single tl.lua file which you can load into your projects. Running tl.loader() will add Teal support to your package loader, meaning that require() will be able to run .tl files.
Genius design.
Lua is a good language. It's like C, if C were a scripting language.
It's got an awesome C API. It's fast, lightweight, and embeddable. It's more performant than Python. It's a staple in video game scripting.
It's nothing like C, and that's so much of its charm.
Semantically, Lua is almost identical to the core of JavaScript. Metatables are a genius alternative to prototype chains.
Lua's syntax is beautifully simple and unambiguous, but at the cost of being moderately inconvenient in 2025 unfortunately. It could benefit from an ESNext-style renewal.
I get why they made the C API that way, but in practice it's very easy to get wrong.
I'm not sure how fast vanilla Lua is today compared to similar languages. I think LuaJIT (and Luau?) are most often used when performance is needed.
Sure, if you compare via semantics Lua and Javascript make sense to liken. But in terms of complexity, Lua is far more like C. There's no unfucking all the horrible decisions baked into javascript and I wouldn't touch it with a ninety-foot pole, but Lua still has some hope.
To be fair Lua also made some bad decisions, though maybe not as bad as javascript:
- tables being used for both objects and arrays can create a lot of confusion, especially when you have some integer keys, but not all, and especially when they are not consecutive or one of them is 0 - indexes start at 1 - assigning nil deinitializes variables/entries instead of assigning the value `nil` (this becomes especially bad if you mistakingly try to use nil as a value in an array/table) - nil and false are falsy, but not 0, which instead is truthy
No disagreement here; I also fundamentally question the cardinal indexing and conflation between table and array. But it's at least internally consistent and certainly makes more sense than mandatorily indexing arrays with floating point.
Every language has warts. Even Lua.
Like another commenter said, using . instead of : is maybe the most common mistake, too easy to make. And Lua offers no help preventing or checking it.
TypeScript is a great language. So is Lua. So is C.
When used carefully to avoid their warts. Learning how to do that for any language takes time and practice though.
> Every language has warts.
Yea, and then there's javascript (or typescript if you prefer), the C++ of scripting languages. It's sometimes difficult to see any value through the warts. (Unless you're paid to, of course.)
Every time someone says this about JavaScript, their favorite language turns out to be something like APL or Ada.
Having a favorite language is weird (to me). They're tools, and some are more effective and usable than others, and some are better suited to some tasks than others.
But, equivalently, of course I'm going to criticize a hammer if it's literally covered in warts making it difficult to grasp without slipping. (or, if the gun I'm trying to use keeps firing bullets into my foot when I'm aiming down range.)
You’re using C as an example of a language that is easy to understand?
C is indeed simple.
The C standard has about 700 pages.
Until you reach the many dark corners of the syntax.
simply don't do that
Unfortunately it's unavoidable for real-world systems.
FYI, for those who may not be aware, moonscript is the "coffeescript" for lua. It has been in production use for quite a while (the author of moonscript also created itch.io, using ... moonscript).
yuescript, from the dora-ssr game engine dev, is essentially moonscript-2.0
And of course, if you want to treat lua as the scheme-like it really is (deep down), then ... fennel.
Lots of choices. They all compile to straightforward lua, are very easy to incorporate (you can even compile at runtime, if you wish), and all employ full lua semantics, meaning zero runtime overhead
EDIT: and the curse of not reading fully ahead strikes again (doh!). Someone else has made the same points below ...
If Teal is the TypeScript of Lua, Fennel is the ClojureScript. Except Fennel is fully implemented in Lua itself and it transpiles (usually) to very simple, plain Lua code without much (if any) overhead and with no run-time library other than what is in Lua itself.
https://fennel-lang.org/
The JavaScript equivalent of Fennel is Sibilant: https://sibilant.org/
I don't think it's a good language, and I hate it. I've made thousands of the same mistakes with it—typing . instead of :. There's a reason Lua has a smaller audience than assembly.
> There's a reason Lua has a smaller audience than assembly.
I don't think that's true. It's a very embedded language. Its use in video games and video game modding alone would outnumber the number of people directly writing assembly to achieve things.
It's also a very old embeddable language, which is probably most of why it's so often chosen for that purpose. Many similar languages have been written from scratch inspired by Lua over the last 10-15 years, some of them almost definitely better than Lua in many respects, but they get no traction because Lua has all the steam. Unfortunate, because the authors of Lua are fairly happy with semantic and syntactic decisions that many of us are very unhappy with.
Or the number of routers that are using it, or other deployable hardware...
Each new Lua version has breaking changes that are of dubious value to keep on the upgrade treadmill. Something like a Python2->3.
LuaJIT is famously on 5.1 with no signs of moving.
Not moving straight to a more recent version, but still cherry-picking some parts of them. You can see some functionalities from Lua 5.2 and 5.3 are working in Luajit: https://luajit.org/extensions.html
I guess all of this means Lua has "flavors" more than "versions".
Teal currenly supports generating code for Lua 5.1 and up, including LuaJIT. There are compiler flags --gen-target and --gen-compat which control various specifics of code generation.
Teal compiles to Lua text files. I believe it's compatible with both Lua 5.1 and 5.4
Oh, clever name. Typed Lua → TL → "Tee Ell" → Teal
And the extension is .tl
Off-topic comment, but as an ESL speaker I just this week randomly learned that teal the color is named after the duck species Anas crecca, called (edit: common or Eurasian) teal in English.
TIL! My wife is a photographer and she's been photographing a ton of Blue-winged Teals over the last couple months during their migration. I assumed that the ducks had been named after the color.
Cool! (Just to be clear, I meant the common, or Eurasian, teal whose iridescent green head markings the color’s apparently named after. The NA teals are closely related, although it seems they were assigned to their own genus in 2009 as it was discovered that the then-Anas was not monophyletic.)
Generally colors are named after things in nature and not the other way around, given that the latter would’be had names for a long time, and most color names are comparatively recent inventions, driven by modern dyes and pigments and status, fashion, etc concerns. A West European peasant in the 11th century would’ve known the bird well, possibly trapped them for food, but would’ve had very little need for a separate word for ”blue-green”.
The history of color words is quite interesting. There’s a specific progression that almost all languages have gone through. It’s fairly well known that many East Asian languages don’t have separate names for ”blue” and ”green” at all (except as modern loans). Accordingly, they don’t usually make the distinction mentally, one could think that they simply consider them hues of ”cyan”.
About blue and green, I know absolutely nothing about this, but I was randomly Wikipedia-surfing a few days ago and found the long page on this topic that is interesting (but has the scary warning at the top about multiple issues).
https://en.wikipedia.org/wiki/Blue%E2%80%93green_distinction...
I'm one of today's lucky 10_000 apparently! Only learned that just now.
There's a type declaration file for the vim global that's defined by default in Neovim: https://github.com/teal-language/teal-types/blob/master/type...
to be used via `global_env_def` described in https://teal-language.org/book/declaration_files.html
And though they mention it as being for third party libraries, this also seems a way to declare types for your own code in an external file, thus keeping your code as runnable Lua and benefiting from type checking too. That seems like a neat workflow for developing Neovim plugins with this: instead of having to constantly regenerate Lua from .tl files so Neovim can pick up your changes during development.
Edit: or maybe https://github.com/teal-language/tl#loading-teal-code-from-l... this is the easier way to do it. `require` and use `loader` during development, generate the Lua once things are somewhat stable.
> this also seems a way to declare types for your own code in an external file, thus keeping your code as runnable Lua and benefiting from type checking too
The declaration file isn't used to typecheck the code the declaration is for. It is only for consumers of the code.
Ah that's a shame. I was hoping it would work via sidecar files like Ruby's RBS [1] or Python's stub files [2]
I was editing my comment during your reply, and added this:
> or maybe https://github.com/teal-language/tl#loading-teal-code-from-l... this is the easier way to do it. `require` and use `loader` during development, generate the Lua once things are somewhat stable.
Does that sound like the right idea then?
[1] https://github.com/ruby/rbs [2] https://mypy.readthedocs.io/en/stable/stubs.html
You can also check this talk from Hissam last fosdem https://fosdem.org/2025/schedule/event/fosdem-2025-6147-what...
I really want to like Lua but I just can’t. Tried Lua/Fennel/even Teal but I just can’t.
I can’t tell what it is exactly. Maybe those weird global rules? Maybe inspection of objects and metatables? Maybe the weird mix of verbose and not verbose (e.g. getting output of a process requiring popen and manual handling but then function can take more arguments than declared and whateva) or exotic control flow and structures (metatable, global env).
It’s interesting language, but I just grit my teeth every time I’m interacting with it.
Has anyone used this? Any reviews? Based on the Github issues, the type system seems to have some holes in it, but it's not obvious how bad is it in real world.
I used it to write a couple Pico-8 games a year or two ago since Lua + dynamic typing is a major obstacle for me managing game code over time. Teal worked well for that.
I'm using it for my game
I'm glad this project isgetting bigger. I remember wathcing the creator hacking on it on twitch back in a day.
This is super cool. I have been using TypeScript To Lua (https://github.com/TypeScriptToLua/TypeScriptToLua) for a little game side project and it works quite well, I am pleased with it. It does end up generating a lot of Lua code though because it has to support all of TypeScript’s features, which isn’t ideal. I’d expect Teal’s output to be much more concise Lua which has me interested.
Teal's output is currently pretty much 1-to-1 with the input apart from removing all of the type information of course. (I've been trying hard to keep it that way so that the error messages in stack traces match the input lines without having to do source mapping.)
I really love teal! Here is a 10k loc project I have in it - https://github.com/Koeng101/libB/blob/dev/src/dnadesign/dnad... - Basically, I reimplemented all my synthetic biology bioinformatics from Go into teal so that LLMs can script with it better in a hermetic environment. It's got all sorts of things like cloning simulation, codon optimization, genbank parsing, synthesis fixing, reliable sequence hashing, sequence analysis, etc. I'm pretty sure it is a more complete synbio library than anything in python, actually.
A couple things I want from teal: 1. I wish there was a better way to bundle files together. I have a little build.lua, but eh, I think it could be better. I know of cyan and everything but I feel like that was developed for a different application than mine. I want to have 1 complete file that I can just give people and allow them to do synbio work in any target language with a lua machine. 2. There are some annoyances around luajit vs lua5.1 functionality 3. The compiler yelling at you gets old for integrating raw lua. I tried to port json.lua in and even with the definition file, I couldn't embed the whole json.lua without having compiler errors. So eventually I just imported it as a string that is type checked, which is bad 4. I really wish syntax highlighting on github was a thing
The good bits:
It's pretty much complete. I used it a couple years ago and there were things with generics that I just couldn't do, but now it is much better. For example, how I use generics for the different parsers (fastq, fasta, genbank, slow5, pileup, etc) https://github.com/Koeng101/libB/blob/dev/src/dnadesign/src/...
Overall, love it! It is one of those pieces of software which is nearly complete, and I love using software like that.
Teal creator here! Thank you for the kind words, super happy to see people being productive with it!!
On your wishlist items:
1. There are a few third-party projects that bundle Lua code. One that comes to mind is https://lrocket.codeberg.page/ — I don't know if this functionality should be brought into Teal itself, it sounds to me like something better left to the surrounding tooling?
2. Unfortunately those annoyances are part of the heterogeinity of the Lua ecosystem, but Teal tries to paper over them using the compat53 library (which, granted, is not available everywhere if you want to do a pure-Lua deployment on existing Lua environments). The --gen-target and --gen-compat flags should still help some, hopefully!
3. Not sure what you mean there -- you mean adding chunks of untyped Lua _in the same file_? I think that if you have a json.lua and a json.d.tl file, then it should use the definition file only and leave the .lua file alone. At least that's the intended behavior!
4. That's up to GitHub :) Last time I checked their docs I think they want something like 100 or 200 projects using the language for considering adding native highlighting for it on the website. But you can add a .gitattributes file to the root of your repository like this https://github.com/teal-language/tl/blob/master/.gitattribut... and at least it will display .tl files with .lua highlighting.
Again, thank you so much for the feedback!
1. Yeah, there are third party bundlers, but none of em worked too well for me. You are right: it should be separate
2. If I recall correctly, gen-target didn't hit it because I was using some very esoteric bullshit from the luajit internal spec that couldn't have nice typing
3. Yes, untyped lua in the same file. The problem is that I want everything in a single file for distribution and embedding - kind of like the SQLite amalgamation. It'd be super cool to just add in my dnadesign.lua or dnadesign.tl file and have full bioinformatics in almost any language! Definition files don't work as well there - I still kind of use them for the type definitions, but then embed the raw file as a string
4. YES THANK YOU! I'm not sure if it is in the docs but this is SO useful!
I really like Lua and I work with it almost daily. But, I hate luarocks. It just don't work well on Windows. And I don't know why. The management of external libraries makes Lua still too difficult to use, which is a real shame considering the qualities of this programming language.
Something to keep an eye out for is Lux: https://github.com/nvim-neorocks/lux. Looks like a promising replacement to Luarocks, but is still pretty early in development.
Tuples: {number, string}
Arrays: {number}
How does it disambiguate it? Are single-element tuples just never used in practice? To be fair, maybe the only time I've had to use them in TypeScript is via Parameters<T>
In our experience, single-element tuples are just never used in practice. There has been some discussion on how to add syntax for them, but I think it's more of a desire for orthogonality than for a practical need.
Yeah I can't imagine any scenario where it's not just a value or an array of values that happens to have only one value right now.
Now I am curious what {number, string, number} would be considered as.
it's a three element tuple.
That was my guess, just as {n, n, n, n} would be a four element tuple, right?
I tried it for one project, but converted it to TypeScript-to-Lua instead.
I used Lua on the backend and my frontend was already in TypeScript, so it was nice that I could reuse the backend types without conversion in the frontend.
I'm getting `TypeError: e is null` by opening this website in a new tab.
Firefox 138.0.1
Please try again, shouldn't be happening, hopefully!
Same, Chromium-based browser on Linux.
This is very cool. I wonder if it works with Roblox, which is probably the environment with the largest number of Lua programmers. It certainly looks like it should work basically anywhere Lua works.
The use their dialect of Lua. Luau, stuck on 5.1 (correct me if I am wrong) like LuaJit for performance reasons.
It is gradually typed, so no need to use Teal.
> Luau, stuck on 5.1 (correct me if I am wrong) like LuaJit for performance reasons.
It's not just for performance reasons, and they don't exactly have no features from newer versions. Take a look at the compatibility tables: https://luau.org/compatibility
Mainly on 5.1
Actually I love luau
the stuck was not expressed as negative, sorry If I gave the wrong impression.
How confident are you in the soundness of the type system?
Also, are there any Lua constructs that are difficult/impossible to type?
Is type checking decidable? (Is the type system Turing complete?)
Hi, Teal creator here!
> How confident are you in the soundness of the type system?
I am confident it is not sound! That is by design. A typical example is how function arguments are bivariant, to allow for callbacks expressed the way programmers usually expect them to work (TypeScript does something similar).
> Also, are there any Lua constructs that are difficult/impossible to type?
Yes, many of them. The type system and the compiler are pragmatically very simple -- there are many design decisions made to favor simplicity of specification and/or implementation. (Compare the single-file, single-pass Teal compiler done mostly by a single person with the amount of engineering resources that Microsoft has put into TypeScript.) For a concrete example, we have special-cased polymorphism for functions, intended to use with very dynamically-typed Lua functions from the broader Lua ecosystem, but you cannot express similar polymorphism in Teal itself.
> Is type checking decidable? (Is the type system Turing complete?)
There is a proof (which I can't find right now) that type checking is not decidable once you combine parametric polymorphism (generics) and intersection types (like the poly functions I mentioned above), but the forms of these features supported by Teal have some restrictions which make me not extend such claims directly. And of course, I can't even claim that the implementation of the theoretical model is bug-free. The model is evolving, the implementation always lags a bit behind.
In any case, the goal for Teal's type system is not academic purity, but pragmatic utility. Other comments in this thread alluded to this as well -- there are practical constraints that come from targeting an existing language and ecosystem. Of course, there are many ways one can approach such challanges. Teal is one of them and there were and are certainly others! Everyone is free to take their shot at where they want to be in the Unix-Philosophy/Worse-is-Better vs. Lisp-Philosophy/The-Right-Thing design gradient.
Thanks for the detailed answer! I just wish the website was more upfront about this. I cannot find anything about "soundness" on the front page or in the docs.
I think you could basically copy your comment into an FAQ section or something on the front page.
People get this way about TypeScript too, and it always perplexes me. These projects are about adding types to untyped languages, and that comes with a few givens:
* Your type system cannot be sound. It's going to have escape hatches and exceptions because that's how dynamic languages roll.
* There will always be constructs that you can't type. See above.
* If your type system is going to usefully type enough of the ecosystem, it will be Turing complete.
All of these things are the trade-offs you make when you set out to layer types on a dynamic language, and they're well worth it to get 99% of the way to type safety in a language that otherwise couldn't scale. Theoretical purity is meaningless if the language isn't useful.
> Your type system cannot be sound.
This one I disagree with. Type assertions with runtime checks could keep the typed fragments sound, unlike TypeScript and Python. Also see Elixir's strong arrow proposal for how to encode which assertions can be elided on function calls (because the function will assert them already).
A tricky tradeoff is that, because Teal compiles to Lua source, adding those run-time type checks would incur some considerable overhead. I've seen other languages in this space easily run 2 or 3 times slower when run-time checks are turned on. It's an open research problem.
You might be interested in checking out Pallene. Like Teal it's also Lua with types but it does check types at run-time, in an efficient way. However, Pallene's type system is currently not as featureful and production ready as Teal.
TypeScript supports runtime type assertions, but it doesn't mandate them or write them for you.
I should have said your type system cannot be sound without runtime overhead. And I don't believe that choosing automatic runtime overhead is the right move.
The problem is not that it doesn't write them for you, but that `as MyType` is way too ergonomic of a syntax for unchecked assertions, whereas checked assertions require effectively parsing the structure manually with typeof checks.
TypeScript desperately needs a way to derive type-guarding functions from types (and so does every gradually-typed language). There're libraries for this but you need to define the types themselves through combinators.
> Your type system cannot be sound. It's going to have escape hatches and exceptions because that's how dynamic languages roll.
I think you could prove that you can't construct a sound & complete type system for Lua. But just saying "Your type system cannot be sound" by itself is definitely wrong. I don't understand why people are throwing out both soundness & completeness, instead of at least retaining one (and I think the choice here is pretty obvious, a sound but incomplete type system is much more useful than an unsound one).
From Flow's website[1] (a type checker for JavaScript):
> Flow tries to be as sound and complete as possible. But because JavaScript was not designed around a type system, Flow sometimes has to make a tradeoff. When this happens Flow tends to favor soundness over completeness, ensuring that code doesn't have any bugs.
I don't understand why other type systems for dynamically typed languages cannot strive for that, and in particular I am pretty salty at TypeScript for explicitly not caring about soundness.
[1]: https://flow.org/en/docs/lang/types-and-expressions/#toc-sou...
Why, though? Completeness matters more than soundness in practice for this kind of language, which is a large part of what gave TypeScript its edge. The only people who complain about soundness seem to be those whose approach to TypeScript is one of theoretical interests rather than practical application.
> How confident are you in the soundness of the type system?
Teal's types are hints, like Python's and TypeScript's, so I suspect it's not sound by design.
> Also, are there any Lua constructs that are difficult/impossible to type?
Teal includes several types that model typical uses of Lua tables, e.g. as arrays, maps etc. It doesn't look like it can type fully general use of Lua tables, e.g. using both the "array part" and "hash part" of the same table.
See also https://ravilang.github.io/ https://nelua.io/
Is it implemented as a compiler, tl, which compiles .tl source code into .lua files? Who knows
Isn't that called a transpiler?
There is another TEAL (uppercase) programming language: <https://developer.algorand.org/docs/get-details/dapps/avm/te...>
I designed and named the Transaction Execution Approval Language for the Algorand blockchain in 2020. I'm partial to the original, but as it grew it got rebranded to be the "Algorand Virtual Machine". Glad someone still remembers it as TEAL!
I vote we give the name to the lua one!
Seconded.
I think you and GP both mean that this TEAL is adjacent to crptocurrency, and therefore, who cares about stepping on toes?
This heuristic works well in most cases maybe, but will lead to false positives sometimes. May I gently suggest that this might be one of those cases. Algorand is the project of this fellow
https://en.m.wikipedia.org/wiki/Silvio_Micali
Credentials aren't faultless but they do provide a certain web of trust. If you browse the academic and professional history of this fellow, I think you'll agree.
Algorand is, I think, as serious and sincere a research project as any other.
I meant that I have a sort of affection for Lua, so it gets preferential treatment in my book, and therefore Teal ought to get the name above another relatively random project with the same name.
Ah ok - fair enough :)
nothing against Algorand, there's just a kind of nice fuzzy feeling that lua gives me. Plus the name is a good pun
Do you know how old that is? Lua Teal has already been around for at least 5 years.
Looks way too similar to Luau.
Oof. What is it about the devs who prefer static typing that they insist on bolting it onto every scripting language they can? It's nearly a compulsive disorder.
There's plenty of languages with compile time type safety, just go use one of them and leave the perfectly good dynamic ones alone.
Static typing proponents need accept that dynamic typing is a perfectly valid way to write and run code: It's way less verbose, it focuses code on logic rather than syntax (a.k.a. "scripting"), it's easier to mentally parse and generally easier to both learn and use.
Inflicting types on every piece of code written is just ridiculous.
Because when your project reaches the 10k lines mark, you want something telling you "Woops, that function you declared only accepts numbers as the first parameter" and there's nothing preventing lua to have minimal compile time safety while also being backward compatible in fact, I think one of the lua transpilers allowed for function (n number, s string, a) (a is any type here)