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

161–170 of 176 posts

Re: Teal – A statically-typed dialect of Lua

#161

Post by 90s_dev »

nmz wrote: post #159
90s_dev wrote: post #9

Earlier quoted context omitted.

It's nothing like C, and that's so much of its charm. Semantically, Lua is almost identical to the core of JavaScript. Metatables are a genius alternative to prototype chains. Lua's syntax is beautifully simple and unambiguous, but at the cost of being moderately inconvenient in 2025 unfortunately. It could benefit from an ESNext-style renewal. I get why they made the C API that way, but in practice it's very easy to…

> Lua's syntax is beautifully simple and unambiguous local print = print ("hello"):format() local foo = func ("args to func"):itreturnedatable("!")

Well of course you can trick people who aren't familiar with its syntax. But people who are see that this is

    local print = print("hello"):format()

    local foo = func("args to func"):itreturnedatable("!")
And I'm sure they can guess that that does.

Re: Teal – A statically-typed dialect of Lua

#162

Post by 90s_dev »

ufo wrote: post #155
SkiFire13 wrote: post #77

Earlier quoted context omitted.

To be fair Lua also made some bad decisions, though maybe not as bad as javascript: - tables being used for both objects and arrays can create a lot of confusion, especially when you have some integer keys, but not all, and especially when they are not consecutive or one of them is 0 - indexes start at 1 - assigning nil deinitializes variables/entries instead of assigning the value `nil` (this becomes especially bad…

Tables being dual purpose is fine. The real problem is that assigning nil deletes the table field. Unfortunately, fixing that now would cause Python3 levels of breakage.

I've never had an issue with =nil being delete. What problem does it cause?

Re: Teal – A statically-typed dialect of Lua

#163

Post by unscaled »

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…

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.

Re: Teal – A statically-typed dialect of Lua

#164

Post by ufo »

90s_dev wrote: post #162
ufo wrote: post #155

Earlier quoted context omitted.

Tables being dual purpose is fine. The real problem is that assigning nil deletes the table field. Unfortunately, fixing that now would cause Python3 levels of breakage.

I've never had an issue with =nil being delete. What problem does it cause?

If you accidentally store nil in an array it creates "holes" inside an array, which breaks the length (#) of the array.

Re: Teal – A statically-typed dialect of Lua

#166

Post by nmz »

russellbeattie wrote: post #157
nmz wrote: post #150

Earlier quoted context omitted.

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)

> "...when your project..." Oof. The same old excuse. So you prematurely optimize your code based on a theoretical line count in the future, cluttering your code with redundant information to save yourself from that one bug you'll encounter in QA anyways. Got it. Makes total sense. I bet you like Java FactoryFactoryImpls as well. If you already know your code will reach 10 kloc in a project where catching a type rela…

> If you already know your code will reach 10 kloc in a project where catching a type related bug is that important, choose an appropriate type safe language. So many wasted man hours dealing with truly pedantic details.

Oh... like teal?

Re: Teal – A statically-typed dialect of Lua

#167

Post by hisham_hm »

nmz wrote: post #151
rfl890 wrote: post #14

Is it implemented as a compiler, tl, which compiles .tl source code into .lua files? Who knows

Isn't that called a transpiler?

"Transpiler" is a common term for source-to-source compilers in the industry, but compiler is the more general term (i.e. a transpiler is a kind of compiler). In academia, the term "transpiler" is somewhat sneered at. A source-to-source compiler is still a compiler, because conceptually compiling into assembly is also technically source-to-source.

Re: Teal – A statically-typed dialect of Lua

#168

Post by nmz »

90s_dev wrote: post #161
nmz wrote: post #159

Earlier quoted context omitted.

> Lua's syntax is beautifully simple and unambiguous local print = print ("hello"):format() local foo = func ("args to func"):itreturnedatable("!")

Well of course you can trick people who aren't familiar with its syntax. But people who are see that this is local print = print("hello"):format() local foo = func("args to func"):itreturnedatable("!") And I'm sure they can guess that that does.

I didn't trick anybody, this was a pitfall that was patched in 5.2

Re: Teal – A statically-typed dialect of Lua

#169

Post by pmarreck »

nmz wrote: post #158
pmarreck wrote: post #95

Earlier quoted context omitted.

I haven’t found many downsides yet. I was already starting to rewrite some things in Awk (which I was drawn to for similar reasons- fast script startup time, simple easy language with good defaults), but Awk (while still also awesome) isn’t really designed for stuff beyond a certain size (no signal handling unless you use a fork, for example) LuaJIT is missing bignums, ints that aren’t floats, bit operations, and nat…

For bignums, have you tried this? https://web.tecgraf.puc-rio.br/~lhf/ftp/lua/#limath luajit does have integers (try 5ull+6), bit operations via the bit library (absorbed from lua5.2)

How does imath compare to gmp?

Re: Teal – A statically-typed dialect of Lua

#170

Post by pmarreck »

nmz wrote: post #113
jiehong wrote: post #69

Earlier quoted context omitted.

Any recommendations going from bash to lua to watch out for except indexing?

I do think you're better off using ruby, but if you insist. Lots of default functionality missing so you MUST have these packages: inspect, luaposix, lrexlib-pcre, lrexlib-posix, lpeg, luastd/stdlib, luasocket, luahttp, luasec, luacheck, penlight * luajit is unnecessary in almost all cases, you don't need the speed. * use lsp or luacheck whenever you write something, entr -c luacheck file on everything. * patterns ar…

Ruby has a startup time and is slow. (Although compiled Crystal might be an idea...)

I am specifically looking for a language that:

1) is a scripting language (don't have to worry about compiling it)

2) starts up fast (so if I use it in a loop or a sequence of pipes, it won't necessarily be the bottleneck)

3) runs fast

4) is easy to work with and is either ridiculously simple or well-designed (Bash has so many footguns...), and scales up to medium-size code (anything that would take more than 1 file to implement should be promoted to another language)

Awk fit this. So did D, actually. Lua certainly does.

> luajit is unnecessary

Why not use it if it's there, it's faster, and you don't need features beyond 5.1?

> patterns are not regex

They're almost regex, they're faster than regex, and for 90% of use cases, you don't need full regex

> tables which is a weird data structure

Isn't a table basically just a JavaScript object, where metatables are the prototype object? Sort of, at least...

Post reply on HN