←back to thread

219 points generichuman | 2 comments | | HN request time: 0.403s | source
Show context
90s_dev ◴[] No.44000882[source]
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.

replies(5): >>44000888 #>>44000949 #>>44001419 #>>44004694 #>>44005269 #
RS-232 ◴[] No.44000949[source]
Lua is a good language. It's like C, if C were a scripting language.

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.

replies(2): >>44001017 #>>44001045 #
90s_dev ◴[] No.44001017[source]
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 get wrong.

I'm not sure how fast vanilla Lua is today compared to similar languages. I think LuaJIT (and Luau?) are most often used when performance is needed.

replies(3): >>44001116 #>>44001427 #>>44011089 #
growlNark ◴[] No.44001116[source]
Sure, if you compare via semantics Lua and Javascript make sense to liken. But in terms of complexity, Lua is far more like C. There's no unfucking all the horrible decisions baked into javascript and I wouldn't touch it with a ninety-foot pole, but Lua still has some hope.
replies(3): >>44001131 #>>44004578 #>>44006694 #
SkiFire13 ◴[] No.44004578[source]
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 if you mistakingly try to use nil as a value in an array/table) - nil and false are falsy, but not 0, which instead is truthy

replies(2): >>44006456 #>>44010616 #
1. ufo ◴[] No.44010616[source]
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.
replies(1): >>44011698 #
2. 90s_dev ◴[] No.44011698[source]
I've never had an issue with =nil being delete. What problem does it cause?