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.
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.
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.
> 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.
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?
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.
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.
> 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.
> 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).
I've had a similar journey to you — I've gotten familiar with Lua through using embedded Lua in apps like Neovim, Hammerspoon, Sbarlua and Wezterm. But unfortunately I feel the exact opposite: the more I use Lua, the more I hate it.
Lua doesn't have as many warts as languages like JavaScript or PHP do. The worst offenders are probably the 1-indexing (more of an stdlib issue than a language issue) and variables being global by default (same as JavaScript). It's a minimalist language and I guess this is one of the reason it is so popular as embedded language. But that's exactly why I find myself preferring even (modern) JavaScript to Lua. Lua is so barebones it's just too painful to use for anyone who got used to programming in other languages.
> 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 that's the crux of it. I guess many people are fine with writing tons of WET code using a barebones library and a bunch of copy-pasted code files thrown around when it comes to their personal scripts. That's all fine, but my brain isn't wired that way and I just feel excruciating pain every time I realize I have to write Lua again.
Luarocks is painful to use, but the main problem is that every embedded Lua you use deals with packages differently. Lua 5.1, 5.2, 5.3, 5.4 and LuaJIT are all incompatible with each other, since every version has breaking changes. Additionally, due to the lack of a standard library, many lua packages have to rely on native code, which makes portability and compatibility even worse. It all means that Lua doesn't really have a package ecosystem.
> But lua isn't like that. It's not weakly typed like JavaScript - it's more akin to pythons dynamic duck typing
I don't understand how Lua is less weakly typed than Java. Both of these languages have dynamic typing and do not support any type annotations or type inference in their core dialects, and both languages have "duck typing".
Where I feel JavaScript is vastly superior to Lua is tooling. JavaScript linters and language servers are far more advanced than Lua language servers, to the point where they can detect a lot of errors that I would waste hours on debugging with Lua. Due to Lua's atrociously bad error messages, without writing a lot of error handling code and copious printf statements, it would be quite hard to find where you've even made a typo in a variable name once your code gets large enough.
So yeah, I get why for some people Lua can be fun, because it's conceptually minimalist, but in practice I hate it with passion.
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
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.
> but turns out it's a perfect language to rewrite some commandline scripts I had that were getting unwieldy in Bash
IMO this is the perfect use case for Perl. I mean, it's why Perl was invented, but to this day it remains incredibly good at doing this specific task. It's incredibly easy to write and can be very easy to read, and it's much more robust than bash. But best of all - and the reason I think Perl still has a place in the modern world - it's available on practically every computer on Earth. And it will all work. It's so backwards-compatible that 25 year old scripts will run just fine. It's so portable that nothing even comes close. Also, it's shockingly fast. Faster than you would think. Regex is really powerful and it's been the template for so many regex implementations, but definitely be careful of runaway time complexity.
Anyway, Lua is great too. Really nice for embedding into applications ala VBA. Great for config.
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.
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'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.
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.
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.
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 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 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.
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.
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.
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 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.
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?
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.
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.
> 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.
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)
pansa2|9 months ago
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
creatonez|9 months ago
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.
SoylentOrange|9 months ago
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.
lifthrasiir|9 months ago
[1] https://github.com/devcat-studio/kailua/
90s_dev|9 months ago
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.
wyldfire|9 months ago
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.
Benjamin_Dobell|9 months ago
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...
ufo|9 months ago
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?
TulliusCicero|9 months ago
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.
0xFEE1DEAD|9 months ago
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.
augusto-moura|9 months ago
[1]: https://github.com/nvim-neorocks/lux
lr1970|9 months ago
And indexing arrays starting from 1 rather than 0.
giraffe_lady|9 months ago
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.
90s_dev|9 months ago
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).
unscaled|9 months ago
Lua doesn't have as many warts as languages like JavaScript or PHP do. The worst offenders are probably the 1-indexing (more of an stdlib issue than a language issue) and variables being global by default (same as JavaScript). It's a minimalist language and I guess this is one of the reason it is so popular as embedded language. But that's exactly why I find myself preferring even (modern) JavaScript to Lua. Lua is so barebones it's just too painful to use for anyone who got used to programming in other languages.
> 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 that's the crux of it. I guess many people are fine with writing tons of WET code using a barebones library and a bunch of copy-pasted code files thrown around when it comes to their personal scripts. That's all fine, but my brain isn't wired that way and I just feel excruciating pain every time I realize I have to write Lua again.
Luarocks is painful to use, but the main problem is that every embedded Lua you use deals with packages differently. Lua 5.1, 5.2, 5.3, 5.4 and LuaJIT are all incompatible with each other, since every version has breaking changes. Additionally, due to the lack of a standard library, many lua packages have to rely on native code, which makes portability and compatibility even worse. It all means that Lua doesn't really have a package ecosystem.
> But lua isn't like that. It's not weakly typed like JavaScript - it's more akin to pythons dynamic duck typing
I don't understand how Lua is less weakly typed than Java. Both of these languages have dynamic typing and do not support any type annotations or type inference in their core dialects, and both languages have "duck typing".
Where I feel JavaScript is vastly superior to Lua is tooling. JavaScript linters and language servers are far more advanced than Lua language servers, to the point where they can detect a lot of errors that I would waste hours on debugging with Lua. Due to Lua's atrociously bad error messages, without writing a lot of error handling code and copious printf statements, it would be quite hard to find where you've even made a typo in a variable name once your code gets large enough.
So yeah, I get why for some people Lua can be fun, because it's conceptually minimalist, but in practice I hate it with passion.
pmarreck|9 months ago
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!
Rochus|9 months ago
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).
jwatte|9 months ago
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
const_cast|9 months ago
IMO this is the perfect use case for Perl. I mean, it's why Perl was invented, but to this day it remains incredibly good at doing this specific task. It's incredibly easy to write and can be very easy to read, and it's much more robust than bash. But best of all - and the reason I think Perl still has a place in the modern world - it's available on practically every computer on Earth. And it will all work. It's so backwards-compatible that 25 year old scripts will run just fine. It's so portable that nothing even comes close. Also, it's shockingly fast. Faster than you would think. Regex is really powerful and it's been the template for so many regex implementations, but definitely be careful of runaway time complexity.
Anyway, Lua is great too. Really nice for embedding into applications ala VBA. Great for config.
kanbankaren|9 months ago
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.
jiehong|9 months ago
samiv|9 months ago
- 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...
augusto-moura|9 months ago
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/
Llamamoe|9 months ago
spookie|9 months ago
nicce|9 months ago
90s_dev|9 months ago
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.
90s_dev|9 months ago
Genius design.
0cf8612b2e1e|9 months ago
LuaJIT is famously on 5.1 with no signs of moving.
RS-232|9 months ago
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.
hisham_hm|9 months ago
ufo|9 months ago
alanh|9 months ago
And the extension is .tl
Sharlin|9 months ago
phant0mas|9 months ago
sundarurfriend|9 months ago
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.
andreypopp|9 months ago
The declaration file isn't used to typecheck the code the declaration is for. It is only for consumers of the code.
HexDecOctBin|9 months ago
hombre_fatal|9 months ago
andre-la|9 months ago
wslh|9 months ago
brianolson|9 months ago
tkzed49|9 months ago
ufo|9 months ago
xlii|9 months ago
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.
unknown|9 months ago
[deleted]
max0563|9 months ago
hisham_hm|9 months ago
koeng|9 months ago
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.
hisham_hm|9 months ago
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!
k__|9 months ago
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.
90s_dev|9 months ago
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>
hisham_hm|9 months ago
johnisgood|9 months ago
pesnk|9 months ago
nicoloren|9 months ago
paranoidxprod|9 months ago
yyx|9 months ago
Firefox 138.0.1
hisham_hm|9 months ago
johnisgood|9 months ago
CobrastanJorji|9 months ago
fithisux|9 months ago
It is gradually typed, so no need to use Teal.
kuruczgy|9 months ago
Also, are there any Lua constructs that are difficult/impossible to type?
Is type checking decidable? (Is the type system Turing complete?)
hisham_hm|9 months ago
> 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.
lolinder|9 months ago
* 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.
pansa2|9 months ago
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.
sitkack|9 months ago
rfl890|9 months ago
nmz|9 months ago
kachapopopow|9 months ago
pakigrapeparty|9 months ago
[deleted]
russellbeattie|9 months ago
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.
nmz|9 months ago