Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Teal – A statically-typed dialect of Lua

teal-language.org

Post reply on HN
Print view View original

131–140 of 176 posts

Re: Teal – A statically-typed dialect of Lua

#131

Post by chamomeal »

koito17 wrote: post #53
creatonez wrote: post #44

Earlier quoted context omitted.

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

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

Re: Teal – A statically-typed dialect of Lua

#132

Post by giraffe_lady »

0xFEE1DEAD wrote: post #73

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

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

Re: Teal – A statically-typed dialect of Lua

#133

Post by pmarreck »

Rochus wrote: post #126
pmarreck wrote: post #116

Earlier quoted context omitted.

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…

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

Re: Teal – A statically-typed dialect of Lua

#134

Post by WorldMaker »

koito17 wrote: post #53
creatonez wrote: post #44

Earlier quoted context omitted.

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

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

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

Re: Teal – A statically-typed dialect of Lua

#135

Post by WorldMaker »

chamomeal wrote: post #131
koito17 wrote: post #53

Earlier quoted context omitted.

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

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

Re: Teal – A statically-typed dialect of Lua

#136

Post by dottrap »

90s_dev wrote: post #123
andre-la wrote: post #120

Earlier quoted context omitted.

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

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.

Re: Teal – A statically-typed dialect of Lua

#137

Post by fithisux »

LoganDark wrote: post #58
fithisux wrote: post #42

Earlier quoted context omitted.

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.

Re: Teal – A statically-typed dialect of Lua

#138

Post by 90s_dev »

dottrap wrote: post #136
90s_dev wrote: post #123

Earlier quoted context omitted.

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

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, spe…

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

Re: Teal – A statically-typed dialect of Lua

#140

Post by ufo »

dottrap wrote: post #136
90s_dev wrote: post #123

Earlier quoted context omitted.

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

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, spe…

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.
Post reply on HN