Teal – A statically-typed dialect of Lua

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.

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

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

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

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