> <i>Teal is a statically-typed dialect of Lua.</i><p>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?<p>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.<p>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"?<p>[0] <a href="https://youtu.be/Uq_8bckDxaU?t=1618" rel="nofollow">https://youtu.be/Uq_8bckDxaU?t=1618</a>
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.<p>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.<p>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 <i>type</i> is straightforward compared to python, mostly because there are only five basic types (technically seven but I've never used <i>userdata</i> or <i>thread</i>).
And I even started to enjoy using metatables once I understood how and when to apply them.<p>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.<p>All that being said, I don't really see the point of using this project.<p>While I do wish type annotations were a native feature, the ones provided by the lsp are good enough for me.
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.<p>LuaJITted Lua code runs at 80% (on average, sometimes faster!) of the <i>compiled C version of the same algorithm</i>, typically. Lua is embedded in a surprisingly massive number of products: <a href="https://en.wikipedia.org/wiki/List_of_applications_using_Lua" rel="nofollow">https://en.wikipedia.org/wiki/List_of_applications_using_Lua</a> The startup time of a script is in nanoseconds. An "echo" written in Lua <i>runs faster than the native echo implementation</i>.<p>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...)<p>Anyway, there's nothing else like it out there. Especially with its relative simplicity.<p>There are also some neat languages that compile to (transpile to?) Lua, and deserve more attention, such as YueScript <a href="https://yuescript.org/" rel="nofollow">https://yuescript.org/</a>, which is a still actively-updated enhanced dialect of MoonScript <a href="https://moonscript.org/" rel="nofollow">https://moonscript.org/</a> (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 <a href="https://typescripttolua.github.io/" rel="nofollow">https://typescripttolua.github.io/</a>, which takes advantage of ALL the existing TypeScript tooling, it just outputs Lua instead of JS!
After having embedded Lua in my game engine and having worked with some Lua games I've come to conclusion that:<p>- 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.<p>- 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.<p>- 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]<p><a href="https://github.com/ensisoft/detonator/blob/master/screens/editor-script.png">https://github.com/ensisoft/detonator/blob/master/screens/ed...</a>
I'm <i>so relieved</i> to see more types being added to good languages.<p>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.<p>What version of Lua does it use? Lua gets new versions every few <i>years</i> so I don't know why so many impls don't continuously upgrade to the latest version.
You can also check this talk from Hissam last fosdem <a href="https://fosdem.org/2025/schedule/event/fosdem-2025-6147-what-should-teal-be-musings-on-foss-project-directions/" rel="nofollow">https://fosdem.org/2025/schedule/event/fosdem-2025-6147-what...</a>
There's a type declaration file for the vim global that's defined by default in Neovim: <a href="https://github.com/teal-language/teal-types/blob/master/types/neovim/vim.d.tl">https://github.com/teal-language/teal-types/blob/master/type...</a><p>to be used via `global_env_def` described in <a href="https://teal-language.org/book/declaration_files.html" rel="nofollow">https://teal-language.org/book/declaration_files.html</a><p>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.<p>Edit: or maybe <a href="https://github.com/teal-language/tl#loading-teal-code-from-lua">https://github.com/teal-language/tl#loading-teal-code-from-l...</a> this is the easier way to do it. `require` and use `loader` during development, generate the Lua once things are somewhat stable.
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.
There is another TEAL (uppercase) programming language: <<a href="https://developer.algorand.org/docs/get-details/dapps/avm/teal/" rel="nofollow">https://developer.algorand.org/docs/get-details/dapps/avm/te...</a>>
I really want to like Lua but I just can’t. Tried Lua/Fennel/even Teal but I just can’t.<p>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).<p>It’s interesting language, but I just grit my teeth every time I’m interacting with it.
This is super cool. I have been using TypeScript To Lua (<a href="https://github.com/TypeScriptToLua/TypeScriptToLua">https://github.com/TypeScriptToLua/TypeScriptToLua</a>) 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.
I really love teal! Here is a 10k loc project I have in it - <a href="https://github.com/Koeng101/libB/blob/dev/src/dnadesign/dnadesign.tl">https://github.com/Koeng101/libB/blob/dev/src/dnadesign/dnad...</a> - 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.<p>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<p>The good bits:<p>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) <a href="https://github.com/Koeng101/libB/blob/dev/src/dnadesign/src/bio/bio.tl">https://github.com/Koeng101/libB/blob/dev/src/dnadesign/src/...</a><p>Overall, love it! It is one of those pieces of software which is nearly complete, and I love using software like that.
I tried it for one project, but converted it to TypeScript-to-Lua instead.<p>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.
Tuples: {number, string}<p>Arrays: {number}<p>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>
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.
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.
How confident are you in the soundness of the type system?<p>Also, are there any Lua constructs that are difficult/impossible to type?<p>Is type checking decidable? (Is the type system Turing complete?)
See also <a href="https://ravilang.github.io/" rel="nofollow">https://ravilang.github.io/</a> <a href="https://nelua.io/" rel="nofollow">https://nelua.io/</a>
Oof. What is it about the devs who prefer static typing that they <i>insist</i> on bolting it onto every scripting language they can? It's nearly a compulsive disorder.<p>There's plenty of languages with compile time type safety, just go use one of them and leave the perfectly good dynamic ones alone.<p>Static typing proponents need accept that dynamic typing is a perfectly valid way to write and run code: It's <i>way</i> 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.<p>Inflicting types on every piece of code written is just ridiculous.