[pansa2]

> 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

[creatonez]

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.

[koito17]

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

[chamomeal]

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!!

[WorldMaker]

> 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.

[WorldMaker]

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).

[VoidWhisperer]

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

[SoylentOrange]

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.

[pansa2]

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.

[thristian]

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.

[lifthrasiir]

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/

[90s_dev]

> 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.

[pansa2]

> 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.

[dottrap]

>> 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

[90s_dev]

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.

[andre-la]

> 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

[90s_dev]

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?

[lifthrasiir]

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.

[90s_dev]

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.

[ufo]

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.

[tiffanyh]

> 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?

[krapp]

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.

[90s_dev]

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.

[wyldfire]

> 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.

[Benjamin_Dobell]

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...

[ufo]

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?

[TulliusCicero]

> 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.