[HN Gopher] Teal - A statically-typed dialect of Lua
___________________________________________________________________
Teal - A statically-typed dialect of Lua
Author : generichuman
Score : 212 points
Date : 2025-05-16 00:40 UTC (22 hours ago)
(HTM) web link (teal-language.org)
(TXT) w3m dump (teal-language.org)
| wslh wrote:
| There is another TEAL (uppercase) programming language:
| <https://developer.algorand.org/docs/get-details/dapps/avm/te...>
| tkzed49 wrote:
| I vote we give the name to the lua one!
| 90s_dev wrote:
| Seconded.
| ayrtondesozzla wrote:
| I think you and GP both mean that this TEAL is adjacent to
| crptocurrency, and therefore, who cares about stepping on
| toes?
|
| This heuristic works well in most cases maybe, but will
| lead to false positives sometimes. May I gently suggest
| that this might be one of those cases. Algorand is the
| project of this fellow
|
| https://en.m.wikipedia.org/wiki/Silvio_Micali
|
| Credentials aren't faultless but they do provide a certain
| web of trust. If you browse the academic and professional
| history of this fellow, I think you'll agree.
|
| Algorand is, I think, as serious and sincere a research
| project as any other.
| 90s_dev wrote:
| I meant that I have a sort of affection for Lua, so it
| gets preferential treatment in my book, and therefore
| Teal ought to get the name above another relatively
| random project with the same name.
| ayrtondesozzla wrote:
| Ah ok - fair enough :)
| tkzed49 wrote:
| nothing against Algorand, there's just a kind of nice
| fuzzy feeling that lua gives me. Plus the name is a good
| pun
| ufo wrote:
| Do you know how old that is? Lua Teal has already been around
| for at least 5 years.
| brianolson wrote:
| I designed and named the Transaction Execution Approval
| Language for the Algorand blockchain in 2020. I'm partial to
| the original, but as it grew it got rebranded to be the
| "Algorand Virtual Machine". Glad someone still remembers it as
| TEAL!
| 90s_dev wrote:
| 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.
| 90s_dev wrote:
| > The core compiler has no dependencies and is implemented as a
| single tl.lua file which you can load into your projects.
| Running tl.loader() will add Teal support to your package
| loader, meaning that require() will be able to run .tl files.
|
| Genius design.
| RS-232 wrote:
| 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.
| 90s_dev wrote:
| 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.
| growlNark wrote:
| 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.
| 90s_dev wrote:
| _Every_ language has warts. Even Lua.
|
| Like another commenter said, using . instead of : is
| maybe _the_ most common mistake, _too easy_ to make. And
| Lua offers no help preventing or checking it.
|
| TypeScript is a great language. So is Lua. So is C.
|
| When used _carefully_ to avoid their warts. Learning how
| to do that for any language takes time and practice
| though.
| growlNark wrote:
| > Every language has warts.
|
| Yea, and then there's javascript (or typescript if you
| prefer), the C++ of scripting languages. It's sometimes
| difficult to see any value through the warts. (Unless
| you're paid to, of course.)
| 90s_dev wrote:
| Every time someone says this about JavaScript, their
| favorite language turns out to be something like APL or
| Ada.
| growlNark wrote:
| Having a favorite language is weird (to me). They're
| tools, and some are more effective and usable than
| others, and some are better suited to some tasks than
| others.
|
| But, equivalently, of course I'm going to criticize a
| hammer if it's literally covered in warts making it
| difficult to grasp without slipping. (or, if the gun I'm
| trying to use keeps firing bullets into my foot when I'm
| aiming down range.)
| SkiFire13 wrote:
| 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
| growlNark wrote:
| No disagreement here; I also fundamentally question the
| cardinal indexing and conflation between table and array.
| But it's at least internally consistent and certainly
| makes more sense than mandatorily indexing arrays with
| floating point.
| xigoi wrote:
| You're using _C_ as an example of a language that is
| _easy_ to understand?
| spookie wrote:
| C is indeed simple.
| Rochus wrote:
| Until you reach the many dark corners of the syntax.
| DaSHacka wrote:
| simply don't do that
| Rochus wrote:
| Unfortunately it's unavoidable for real-world systems.
| xigoi wrote:
| The C standard has about 700 pages.
| isr wrote:
| FYI, for those who may not be aware, moonscript is the
| "coffeescript" for lua. It has been in production use for
| quite a while (the author of moonscript also created
| itch.io, using ... moonscript).
|
| yuescript, from the dora-ssr game engine dev, is
| essentially moonscript-2.0
|
| And of course, if you want to treat lua as the scheme-like
| it really is (deep down), then ... fennel.
|
| Lots of choices. They all compile to straightforward lua,
| are very easy to incorporate (you can even compile at
| runtime, if you wish), and all employ full lua semantics,
| meaning zero runtime overhead
|
| EDIT: and the curse of not reading fully ahead strikes
| again (doh!). Someone else has made the same points below
| ...
| 3036e4 wrote:
| If Teal is the TypeScript of Lua, Fennel is the
| ClojureScript. Except Fennel is fully implemented in Lua
| itself and it transpiles (usually) to very simple, plain
| Lua code without much (if any) overhead and with no run-
| time library other than what is in Lua itself.
|
| https://fennel-lang.org/
| xigoi wrote:
| The JavaScript equivalent of Fennel is Sibilant:
| https://sibilant.org/
| RonaldK9 wrote:
| I don't think it's a good language, and I hate it. I've made
| thousands of the same mistakes with it--typing . instead of
| :. There's a reason Lua has a smaller audience than assembly.
| Philpax wrote:
| > There's a reason Lua has a smaller audience than
| assembly.
|
| I don't think that's true. It's a _very_ embedded language.
| Its use in video games and video game modding alone would
| outnumber the number of people directly writing assembly to
| achieve things.
| shakna wrote:
| Or the number of routers that are using it, or other
| deployable hardware...
| 90s_dev wrote:
| It's also a very _old_ embeddable language, which is
| probably most of why it 's so often chosen for that
| purpose. Many similar languages have been written from
| scratch inspired by Lua over the last 10-15 years, some
| of them almost definitely _better_ than Lua in _many_
| respects, but they get no traction because Lua has all
| the steam. Unfortunate, because the authors of Lua are
| fairly happy with semantic and syntactic decisions that
| many of us are very _unhappy_ with.
| 0cf8612b2e1e wrote:
| Each new Lua version has breaking changes that are of dubious
| value to keep on the upgrade treadmill. Something like a
| Python2->3.
|
| LuaJIT is famously on 5.1 with no signs of moving.
| bondant wrote:
| Not moving straight to a more recent version, but still
| cherry-picking some parts of them. You can see some
| functionalities from Lua 5.2 and 5.3 are working in Luajit:
| https://luajit.org/extensions.html
| 90s_dev wrote:
| I guess all of this means Lua has "flavors" more than
| "versions".
| ufo wrote:
| Teal compiles to Lua text files. I believe it's compatible with
| both Lua 5.1 and 5.4
| hisham_hm wrote:
| Teal currenly supports generating code for Lua 5.1 and up,
| including LuaJIT. There are compiler flags --gen-target and
| --gen-compat which control various specifics of code
| generation.
| alanh wrote:
| Oh, clever name. Typed Lua - TL - "Tee Ell" - Teal
|
| And the extension is .tl
| Sharlin wrote:
| Off-topic comment, but as an ESL speaker I just this week
| randomly learned that teal the color is named after the duck
| species _Anas crecca_ , called (edit: common or Eurasian) teal
| in English.
| seafoamteal wrote:
| I'm one of today's lucky 10_000 apparently! Only learned that
| just now.
| nozzlegear wrote:
| TIL! My wife is a photographer and she's been photographing a
| ton of Blue-winged Teals over the last couple months during
| their migration. I assumed that the ducks had been named
| after the color.
| Sharlin wrote:
| Cool! (Just to be clear, I meant the common, or Eurasian,
| teal whose iridescent green head markings the color's
| apparently named after. The NA teals are closely related,
| although it seems they were assigned to their own genus in
| 2009 as it was discovered that the then- _Anas_ was not
| monophyletic.)
|
| Generally colors are named after things in nature and not
| the other way around, given that the latter would'be had
| names for a long time, and most color names are
| comparatively recent inventions, driven by modern dyes and
| pigments and status, fashion, etc concerns. A West European
| peasant in the 11th century would've known the bird well,
| possibly trapped them for food, but would've had very
| little need for a separate word for "blue-green".
|
| The history of color words is quite interesting. There's a
| specific progression that almost all languages have gone
| through. It's fairly well known that many East Asian
| languages don't have separate names for "blue" and "green"
| at all (except as modern loans). Accordingly, they don't
| usually make the distinction mentally, one could think that
| they simply consider them hues of "cyan".
| 3036e4 wrote:
| About blue and green, I know absolutely nothing about
| this, but I was randomly Wikipedia-surfing a few days ago
| and found the long page on this topic that is interesting
| (but has the scary warning at the top about multiple
| issues).
|
| https://en.wikipedia.org/wiki/Blue%E2%80%93green_distinct
| ion...
| 90s_dev wrote:
| Tuples: {number, string}
|
| Arrays: {number}
|
| How does it disambiguate it? Are single-element tuples just never
| used in practice? To be fair, maybe the only time I've had to use
| them in TypeScript is via Parameters<T>
| johnisgood wrote:
| Now I am curious what {number, string, number} would be
| considered as.
| hisham_hm wrote:
| it's a three element tuple.
| johnisgood wrote:
| That was my guess, just as {n, n, n, n} would be a four
| element tuple, right?
| hisham_hm wrote:
| In our experience, single-element tuples are just never used in
| practice. There has been some discussion on how to add syntax
| for them, but I think it's more of a desire for orthogonality
| than for a practical need.
| 90s_dev wrote:
| Yeah I can't imagine any scenario where it's not just a value
| or an array of values that happens to have only one value
| right now.
| rfl890 wrote:
| _Is_ it implemented as a compiler, tl, which compiles .tl source
| code into .lua files? Who knows
| nmz wrote:
| Isn't that called a transpiler?
| HexDecOctBin wrote:
| Has anyone used this? Any reviews? Based on the Github issues,
| the type system seems to have some holes in it, but it's not
| obvious how bad is it in real world.
| hombre_fatal wrote:
| I used it to write a couple Pico-8 games a year or two ago
| since Lua + dynamic typing is a major obstacle for me managing
| game code over time. Teal worked well for that.
| andre-la wrote:
| I'm using it for my game
| pmarreck wrote:
| I've been diving into Lua (a little late to this party, but turns
| out it's a perfect language to rewrite some commandline scripts I
| had that were getting unwieldy in Bash, especially with LLM
| assistance!) and it's really something of an eye-opener.
|
| LuaJITted Lua code runs at 80% (on average, sometimes faster!) of
| the _compiled C version of the same algorithm_ , typically. Lua
| is embedded in a surprisingly massive number of products:
| https://en.wikipedia.org/wiki/List_of_applications_using_Lua The
| startup time of a script is in nanoseconds. An "echo" written in
| Lua _runs faster than the native echo implementation_.
|
| The only warts so far are 1-based indexing (you get used to it),
| and the fact that LuaJIT is stuck at Lua 5.1 while Lua itself is
| up to 5.3 or 5.4 and has added some niceties... with Lua proper
| running slower. And no real standard library to speak of
| (although some would argue that's a feature; there are a few
| options and different flavors out there if that's what you need,
| though- Such as functional-flavored ones...)
|
| Anyway, there's nothing else like it out there. Especially with
| its relative simplicity.
|
| There are also some neat languages that compile to (transpile
| to?) Lua, and deserve more attention, such as YueScript
| https://yuescript.org/, which is a still actively-updated
| enhanced dialect of MoonScript https://moonscript.org/ (described
| as "Coffeescript for Lua", although it hasn't been updated in 10
| years) although neither of these are typed. HOWEVER... there IS
| this: TypescriptToLua https://typescripttolua.github.io/, which
| takes advantage of ALL the existing TypeScript tooling, it just
| outputs Lua instead of JS!
| kanbankaren wrote:
| It is true that LuaJIT is stuck at 5.1, but you could write any
| performance critical sections in C/C++ and call it from Lua.
|
| Lack of LuaJIT for 5.1+ isn't that big of a deal for desktop
| apps. The embedded world is still stuck in 5.1, but for them,
| the benefits of the latest Lua is marginal.
| vrighter wrote:
| and if you use luajit ffi, those calls actually get called
| just as fast as from a c program
| johnisgood wrote:
| And despite it being stuck at 5.1, it still implements
| features from other versions. For example, there is the
| "LJ_52" macro, so you can compile "table.pack" and
| "table.unpack" into LuaJIT, which I do, because I use both at
| times.
|
| As someone else have pointed it out, they are cherry picked:
| https://luajit.org/extensions.html.
| hisham_hm wrote:
| There is also the compat53 library which polyfills most of
| the missing parts. The Teal compiler has --gen-target and
| --gen-compat flags which adapts the generated Lua code for
| different Lua versions, and allows using the compat53
| library behind the scenes if desired, so you can get a
| mostly Lua-5.3+ experience over LuaJIT using Teal.
| jiehong wrote:
| Any recommendations going from bash to lua to watch out for
| except indexing?
| pmarreck wrote:
| 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 native utf8 handling, but it can pretty
| easily be extended with libraries, ffi and metatabling. (I
| actually made a working bignum library that integrates with
| gmp, but it has a memory leak somewhere and it's a rabbit
| hole/bikeshedding project at this point...)
|
| LLM assistance helps hugely and I really like YueScript's
| syntax additions. You can point any LLM at a syntax
| describing webpage and it will pretty much write that
| language for you...
| nmz wrote:
| 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 are not regex which means they do not support
| lookups, backtracking or |, so you must install lrexlib-pcre
| or lrexlib-posix (frankly I never need pcre so I stick to
| lrexlib-gnu or lrexlib-posix).
|
| * overload _ENV so it auto requires unknown things, I have a
| lua wrapper that does this and it makes it a joy not having
| all of my scripts with a bunch of require"posix" on all of
| them
|
| * install inspect to inspect tables
|
| * os.execute and io.popen only accepts strings as parameters
| which means you should overload it and make a function that
| accepts tables as well.
|
| * 5.4 is still lacking support for many libraries, 5.3 has
| most of the libraries.
|
| * assignments default to the global environment so you have
| to use local keyword or set _ENV to error on assignment (or
| better yet, don't care, just local _ENV = mymodule)
|
| Overall, Lua is just a mixture of C with a pascal syntax and
| garbage collection (and also tables which is a weird data
| structure)
| Rochus wrote:
| > _LuaJITted Lua code runs at 80% (on average, sometimes
| faster!) of the compiled C version of the same algorithm,
| typically_
|
| Cannot confirm this. It might be true on selected micro
| benchmarks. Here are the results of the Are-we-fast-yet
| benchmark suite, which includes a decent set of benchmarks
| challenging CPU, cache and memory access:
| https://github.com/rochus-
| keller/Oberon/blob/master/testcase....
|
| On average, the C and C++ implementations are five times faster
| than LuaJIT.
|
| > _There are also some neat languages that compile to
| (transpile to?) Lua_
|
| Here is a comprehensive list:
| https://github.com/hengestone/lua-languages. Lanuages like
| Oberon or Luon directly compile to LuaJIT bytecode (i.e. not to
| Lua).
| Symmetry wrote:
| The code in Are-we-fast-yet has been heavily optimized. It
| might still be true that naive LuaJIT can run almost as fast
| as Naive C.
| Rochus wrote:
| Have a look at the results and the code; there are
| benchmarks in the suite where the (ideomatic) C/C++
| implementation is "only" twice as fast as the corresponding
| (idiomatic) Lua implementation, but on average (geomean of
| all factors) it's about five times as fast. The guidelines
| of the benchmark are pretty strict to enable fair
| comparisons (see https://github.com/smarr/are-we-fast-
| yet/blob/master/docs/gu...).
| pmarreck wrote:
| 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
| operators with various Lua versions is a nightmare.
| We use luacheck as a linter.
|
| If they are writing code compatible with Lua 5.2 or 5.3,
| then that cannot be LuaJIT, which is ONLY compatible with
| Lua 5.1. (Unless they mean that they JUST write 5.1 code,
| which due to backwards compatibility is runnable on 5.2
| and 5.3? It's unclear from here.)
| Rochus wrote:
| 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....
| pmarreck wrote:
| This actually gave me an idea that I'm going to build out
| jwatte wrote:
| Another one of the biggest uses of Lua outside the hyperscaler-
| type software like nginx or redis: Roblox. Soooo many kids run
| games on Roblox every day!
|
| Roblox not only runs entirely on Lua, but they've been working
| on their own type inference version of Lua named Luau, and open
| sourced it, and it's still in very active development.
|
| https://github.com/luau-lang/luau
| pansa2 wrote:
| > _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
| Benjamin_Dobell wrote:
| 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...
| lifthrasiir wrote:
| 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/
| wyldfire wrote:
| > 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.
| 90s_dev wrote:
| > 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 wrote:
| > _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 wrote:
| >> 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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?
| dottrap wrote:
| 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.
| 90s_dev wrote:
| 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).
| ufo wrote:
| Alas, as of last month we changed Pallene's compiler and
| it now generates C gotos for control flow. ( ^ _ ^ me )
| It helped with certain optimizations...
| 90s_dev wrote:
| Ha! Called it again!
|
| But why gotos instead of proper control flow? Is it just
| easier to emit?
| ufo wrote:
| 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.
| 90s_dev wrote:
| That's really exciting work. Great job. Hope it's
| fulfilling.
| lifthrasiir wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > _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 wrote:
| 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 wrote:
| 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.
| SoylentOrange wrote:
| 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 wrote:
| 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 wrote:
| 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.
| creatonez wrote:
| 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.
| VoidWhisperer wrote:
| 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
| koito17 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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).
| ufo wrote:
| 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 wrote:
| > 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.
| max0563 wrote:
| This is super cool. I have been using TypeScript To Lua
| (https://github.com/TypeScriptToLua/TypeScriptToLua) for a little
| game side project and it works quite well, I am pleased with it.
| It does end up generating a lot of Lua code though because it has
| to support all of TypeScript's features, which isn't ideal. I'd
| expect Teal's output to be much more concise Lua which has me
| interested.
| hisham_hm wrote:
| Teal's output is currently pretty much 1-to-1 with the input
| apart from removing all of the type information of course.
| (I've been trying hard to keep it that way so that the error
| messages in stack traces match the input lines without having
| to do source mapping.)
| kachapopopow wrote:
| Looks way too similar to Luau.
| CobrastanJorji wrote:
| This is very cool. I wonder if it works with Roblox, which is
| probably the environment with the largest number of Lua
| programmers. It certainly looks like it should work basically
| anywhere Lua works.
| fithisux wrote:
| 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.
| LoganDark wrote:
| > 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
| fithisux wrote:
| Mainly on 5.1
|
| Actually I love luau
|
| the stuck was not expressed as negative, sorry If I gave
| the wrong impression.
| phant0mas wrote:
| You can also check this talk from Hissam last fosdem
| https://fosdem.org/2025/schedule/event/fosdem-2025-6147-what...
| kuruczgy wrote:
| How confident are you in the soundness of the type system?
|
| Also, are there any Lua constructs that are difficult/impossible
| to type?
|
| Is type checking decidable? (Is the type system Turing complete?)
| pansa2 wrote:
| > _How confident are you in the soundness of the type system?_
|
| Teal's types are _hints_ , like Python's and TypeScript's, so I
| suspect it's not sound by design.
|
| > _Also, are there any Lua constructs that are difficult
| /impossible to type?_
|
| Teal includes several types that model typical uses of Lua
| tables, e.g. as arrays, maps etc. It doesn't look like it can
| type fully general use of Lua tables, e.g. using both the
| "array part" and "hash part" of the same table.
| lolinder wrote:
| People get this way about TypeScript too, and it always
| perplexes me. These projects are about adding types to untyped
| languages, and that comes with a few givens:
|
| * Your type system cannot be sound. It's going to have escape
| hatches and exceptions because that's how dynamic languages
| roll.
|
| * There will always be constructs that you can't type. See
| above.
|
| * If your type system is going to usefully type enough of the
| ecosystem, it will be Turing complete.
|
| All of these things are the trade-offs you make when you set
| out to layer types on a dynamic language, and they're well
| worth it to get 99% of the way to type safety in a language
| that otherwise couldn't scale. Theoretical purity is
| meaningless if the language isn't useful.
| kuruczgy wrote:
| > Your type system cannot be sound. It's going to have escape
| hatches and exceptions because that's how dynamic languages
| roll.
|
| I think you could prove that you can't construct a sound &
| complete type system for Lua. But just saying "Your type
| system cannot be sound" by itself is definitely wrong. I
| don't understand why people are throwing out both soundness &
| completeness, instead of at least retaining one (and I think
| the choice here is pretty obvious, a sound but incomplete
| type system is much more useful than an unsound one).
|
| From Flow's website[1] (a type checker for JavaScript):
|
| > Flow tries to be as sound and complete as possible. But
| because JavaScript was not designed around a type system,
| Flow sometimes has to make a tradeoff. When this happens Flow
| tends to favor soundness over completeness, ensuring that
| code doesn't have any bugs.
|
| I don't understand why other type systems for dynamically
| typed languages cannot strive for that, and in particular I
| am pretty salty at TypeScript for explicitly not caring about
| soundness.
|
| [1]: https://flow.org/en/docs/lang/types-and-
| expressions/#toc-sou...
| lolinder wrote:
| Why, though? Completeness matters more than soundness in
| practice for this kind of language, which is a large part
| of what gave TypeScript its edge. The only people who
| complain about soundness seem to be those whose approach to
| TypeScript is one of theoretical interests rather than
| practical application.
| debugnik wrote:
| > Your type system cannot be sound.
|
| This one I disagree with. Type assertions with runtime checks
| could keep the typed fragments sound, unlike TypeScript and
| Python. Also see Elixir's strong arrow proposal for how to
| encode which assertions can be elided on function calls
| (because the function will assert them already).
| lolinder wrote:
| TypeScript supports runtime type assertions, but it doesn't
| mandate them or write them for you.
|
| I should have said your type system cannot be sound without
| runtime overhead. And I don't believe that choosing
| automatic runtime overhead is the right move.
| debugnik wrote:
| The problem is not that it doesn't write them for you,
| but that `as MyType` is way too ergonomic of a syntax for
| unchecked assertions, whereas checked assertions require
| effectively parsing the structure manually with typeof
| checks.
|
| TypeScript desperately needs a way to derive type-
| guarding functions from types (and so does every
| gradually-typed language). There're libraries for this
| but you need to define the types themselves through
| combinators.
| ufo wrote:
| A tricky tradeoff is that, because Teal compiles to Lua
| source, adding those run-time type checks would incur some
| considerable overhead. I've seen other languages in this
| space easily run 2 or 3 times slower when run-time checks
| are turned on. It's an open research problem.
|
| You might be interested in checking out Pallene. Like Teal
| it's also Lua with types but it does check types at run-
| time, in an efficient way. However, Pallene's type system
| is currently not as featureful and production ready as
| Teal.
| hisham_hm wrote:
| Hi, Teal creator here!
|
| > How confident are you in the soundness of the type system?
|
| I am confident it is not sound! That is by design. A typical
| example is how function arguments are bivariant, to allow for
| callbacks expressed the way programmers usually expect them to
| work (TypeScript does something similar).
|
| > Also, are there any Lua constructs that are
| difficult/impossible to type?
|
| Yes, many of them. The type system and the compiler are
| pragmatically very simple -- there are many design decisions
| made to favor simplicity of specification and/or
| implementation. (Compare the single-file, single-pass Teal
| compiler done mostly by a single person with the amount of
| engineering resources that Microsoft has put into TypeScript.)
| For a concrete example, we have special-cased polymorphism for
| functions, intended to use with very dynamically-typed Lua
| functions from the broader Lua ecosystem, but you cannot
| express similar polymorphism in Teal itself.
|
| > Is type checking decidable? (Is the type system Turing
| complete?)
|
| There is a proof (which I can't find right now) that type
| checking is not decidable once you combine parametric
| polymorphism (generics) and intersection types (like the poly
| functions I mentioned above), but the forms of these features
| supported by Teal have some restrictions which make me not
| extend such claims directly. And of course, I can't even claim
| that the implementation of the theoretical model is bug-free.
| The model is evolving, the implementation always lags a bit
| behind.
|
| In any case, the goal for Teal's type system is not academic
| purity, but pragmatic utility. Other comments in this thread
| alluded to this as well -- there are practical constraints that
| come from targeting an existing language and ecosystem. Of
| course, there are many ways one can approach such challanges.
| Teal is one of them and there were and are certainly others!
| Everyone is free to take their shot at where they want to be in
| the Unix-Philosophy/Worse-is-Better vs. Lisp-Philosophy/The-
| Right-Thing design gradient.
| kuruczgy wrote:
| Thanks for the detailed answer! I just wish the website was
| more upfront about this. I cannot find anything about
| "soundness" on the front page or in the docs.
|
| I think you could basically copy your comment into an FAQ
| section or something on the front page.
| koeng wrote:
| I really love teal! Here is a 10k loc project I have in it -
| https://github.com/Koeng101/libB/blob/dev/src/dnadesign/dnad... -
| Basically, I reimplemented all my synthetic biology
| bioinformatics from Go into teal so that LLMs can script with it
| better in a hermetic environment. It's got all sorts of things
| like cloning simulation, codon optimization, genbank parsing,
| synthesis fixing, reliable sequence hashing, sequence analysis,
| etc. I'm pretty sure it is a more complete synbio library than
| anything in python, actually.
|
| A couple things I want from teal: 1. I wish there was a better
| way to bundle files together. I have a little build.lua, but eh,
| I think it could be better. I know of cyan and everything but I
| feel like that was developed for a different application than
| mine. I want to have 1 complete file that I can just give people
| and allow them to do synbio work in any target language with a
| lua machine. 2. There are some annoyances around luajit vs lua5.1
| functionality 3. The compiler yelling at you gets old for
| integrating raw lua. I tried to port json.lua in and even with
| the definition file, I couldn't embed the whole json.lua without
| having compiler errors. So eventually I just imported it as a
| string that is type checked, which is bad 4. I really wish syntax
| highlighting on github was a thing
|
| The good bits:
|
| It's pretty much complete. I used it a couple years ago and there
| were things with generics that I just couldn't do, but now it is
| much better. For example, how I use generics for the different
| parsers (fastq, fasta, genbank, slow5, pileup, etc)
| https://github.com/Koeng101/libB/blob/dev/src/dnadesign/src/...
|
| Overall, love it! It is one of those pieces of software which is
| nearly complete, and I love using software like that.
| hisham_hm wrote:
| Teal creator here! Thank you for the kind words, super happy to
| see people being productive with it!!
|
| On your wishlist items:
|
| 1. There are a few third-party projects that bundle Lua code.
| One that comes to mind is https://lrocket.codeberg.page/ -- I
| don't know if this functionality should be brought into Teal
| itself, it sounds to me like something better left to the
| surrounding tooling?
|
| 2. Unfortunately those annoyances are part of the heterogeinity
| of the Lua ecosystem, but Teal tries to paper over them using
| the compat53 library (which, granted, is not available
| everywhere if you want to do a pure-Lua deployment on existing
| Lua environments). The --gen-target and --gen-compat flags
| should still help some, hopefully!
|
| 3. Not sure what you mean there -- you mean adding chunks of
| untyped Lua _in the same file_? I think that if you have a
| json.lua and a json.d.tl file, then it should use the
| definition file only and leave the .lua file alone. At least
| that's the intended behavior!
|
| 4. That's up to GitHub :) Last time I checked their docs I
| think they want something like 100 or 200 projects using the
| language for considering adding native highlighting for it on
| the website. But you can add a .gitattributes file to the root
| of your repository like this https://github.com/teal-
| language/tl/blob/master/.gitattribut... and at least it will
| display .tl files with .lua highlighting.
|
| Again, thank you so much for the feedback!
| koeng wrote:
| 1. Yeah, there are third party bundlers, but none of em
| worked too well for me. You are right: it should be separate
|
| 2. If I recall correctly, gen-target didn't hit it because I
| was using some very esoteric bullshit from the luajit
| internal spec that couldn't have nice typing
|
| 3. Yes, untyped lua in the same file. The problem is that I
| want everything in a single file for distribution and
| embedding - kind of like the SQLite amalgamation. It'd be
| super cool to just add in my dnadesign.lua or dnadesign.tl
| file and have full bioinformatics in almost any language!
| Definition files don't work as well there - I still kind of
| use them for the type definitions, but then embed the raw
| file as a string
|
| 4. YES THANK YOU! I'm not sure if it is in the docs but this
| is SO useful!
| sitkack wrote:
| See also https://ravilang.github.io/ https://nelua.io/
| russellbeattie wrote:
| Oof. What is it about the devs who prefer static typing that they
| _insist_ on bolting it onto every scripting language they can? It
| 's nearly a compulsive disorder.
|
| There's plenty of languages with compile time type safety, just
| go use one of them and leave the perfectly good dynamic ones
| alone.
|
| Static typing proponents need accept that dynamic typing is a
| perfectly valid way to write and run code: It's _way_ less
| verbose, it focuses code on logic rather than syntax (a.k.a.
| "scripting"), it's easier to mentally parse and generally easier
| to both learn and use.
|
| Inflicting types on every piece of code written is just
| ridiculous.
| nmz wrote:
| 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)
| yyx wrote:
| I'm getting `TypeError: e is null` by opening this website in a
| new tab.
|
| Firefox 138.0.1
| johnisgood wrote:
| Same, Chromium-based browser on Linux.
| hisham_hm wrote:
| Please try again, shouldn't be happening, hopefully!
| xlii wrote:
| I really want to like Lua but I just can't. Tried Lua/Fennel/even
| Teal but I just can't.
|
| I can't tell what it is exactly. Maybe those weird global rules?
| Maybe inspection of objects and metatables? Maybe the weird mix
| of verbose and not verbose (e.g. getting output of a process
| requiring popen and manual handling but then function can take
| more arguments than declared and whateva) or exotic control flow
| and structures (metatable, global env).
|
| It's interesting language, but I just grit my teeth every time
| I'm interacting with it.
| sundarurfriend wrote:
| There's a type declaration file for the vim global that's defined
| by default in Neovim: https://github.com/teal-language/teal-
| types/blob/master/type...
|
| to be used via `global_env_def` described in https://teal-
| language.org/book/declaration_files.html
|
| And though they mention it as being for third party libraries,
| this also seems a way to declare types for your own code in an
| external file, thus keeping your code as runnable Lua and
| benefiting from type checking too. That seems like a neat
| workflow for developing Neovim plugins with this: instead of
| having to constantly regenerate Lua from .tl files so Neovim can
| pick up your changes during development.
|
| Edit: or maybe https://github.com/teal-language/tl#loading-teal-
| code-from-l... this is the easier way to do it. `require` and use
| `loader` during development, generate the Lua once things are
| somewhat stable.
| andreypopp wrote:
| > this also seems a way to declare types for your own code in
| an external file, thus keeping your code as runnable Lua and
| benefiting from type checking too
|
| The declaration file isn't used to typecheck the code the
| declaration is for. It is only for consumers of the code.
| sundarurfriend wrote:
| Ah that's a shame. I was hoping it would work via sidecar
| files like Ruby's RBS [1] or Python's stub files [2]
|
| I was editing my comment during your reply, and added this:
|
| > or maybe https://github.com/teal-language/tl#loading-teal-
| code-from-l... this is the easier way to do it. `require` and
| use `loader` during development, generate the Lua once things
| are somewhat stable.
|
| Does that sound like the right idea then?
|
| [1] https://github.com/ruby/rbs [2]
| https://mypy.readthedocs.io/en/stable/stubs.html
| k__ wrote:
| I tried it for one project, but converted it to TypeScript-to-Lua
| instead.
|
| I used Lua on the backend and my frontend was already in
| TypeScript, so it was nice that I could reuse the backend types
| without conversion in the frontend.
| 0xFEE1DEAD wrote:
| 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 navigating a minefield. The lack of
| type system made it all too easy to introduce bugs.
|
| But lua isn't like that. It's not weakly typed like javascript -
| it's more akin to pythons dynamic duck typing system. Its
| simplicity makes it remarkably easy to write clean maintainable
| code. Type checking with _type_ is straightforward compared to
| python, mostly because there are only five basic types
| (technically seven but I 've never used _userdata_ or _thread_ ).
| And I even started to enjoy using metatables once I understood
| how and when to apply them.
|
| 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.
|
| All that being said, I don't really see the point of using this
| project.
|
| While I do wish type annotations were a native feature, the ones
| provided by the lsp are good enough for me.
| augusto-moura wrote:
| BTW, you might want to check Lux [1], it's a new approach for
| Lua packaging. They launched it recently, so there's a lot of
| work going on. But it looks and feels very promising
|
| [1]: https://github.com/nvim-neorocks/lux
| 90s_dev wrote:
| > But lua isn't like that. It's not weakly typed like
| javascript - it's more akin to pythons dynamic duck typing
| system
|
| What? No, Lua's type system is practically _identical_ to
| JavaScript 's.
|
| Even metatables are extraordinarily similar to prototype chains
| via __index (though much more powerful since they allow for
| operator overloading, which I wish JS had).
| giraffe_lady wrote:
| > 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 se1 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.
|
| 1 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.
| lr1970 wrote:
| > 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 indexing arrays starting from 1 rather than 0.
| pull_my_finger wrote:
| It doesn't "index arrays from 1", it doesn't have arrays, but
| tables, that can operate as "sequences". It's all documented
| in the docs.
|
| >>> A table with exactly one border is called a sequence. For
| instance, the table {10, 20, 30, 40, 50} is a sequence, as it
| has only one border (5). The table {10, 20, 30, nil, 50} has
| two borders (3 and 5), and therefore it is not a sequence.
| (The nil at index 4 is called a hole.) The table {nil, 20,
| 30, nil, nil, 60, nil} has three borders (0, 3, and 6) and
| three holes (at indices 1, 4, and 5), so it is not a
| sequence, too. The table {} is a sequence with border 0. Note
| that non-natural keys do not interfere with whether a table
| is a sequence
| nicoloren wrote:
| I really like Lua and I work with it almost daily. But, I hate
| luarocks. It just don't work well on Windows. And I don't know
| why. The management of external libraries makes Lua still too
| difficult to use, which is a real shame considering the qualities
| of this programming language.
| paranoidxprod wrote:
| Something to keep an eye out for is Lux:
| https://github.com/nvim-neorocks/lux. Looks like a promising
| replacement to Luarocks, but is still pretty early in
| development.
| pesnk wrote:
| I'm glad this project isgetting bigger. I remember wathcing the
| creator hacking on it on twitch back in a day.
| samiv wrote:
| After having embedded Lua in my game engine and having worked
| with some Lua games I've come to conclusion that:
|
| - Lua is great from the integrator/engine dev perspective. It's
| easy to embed and there are several libraries that help with
| creating bindings between Lua and your game classes.
|
| - Lua has absolutely terrible runtime performance especially when
| the GC stalls. You soon learn that you have to start moving code
| to the native side and carefully consider the APIs that you
| provide for the game so that you can even dream of any type of
| performance. Haven't tried LuaJIT since that doesn't work with
| WASM so it's not an option for me.
|
| - The loose runtime typing in Lua is absolutely terrible, and
| while it's easy and fast to knock up some simple script you
| really pay the price when you try to maintain or refactor your
| code and you have no typing information. For the game engine
| developer this also makes it very hard to provide any kind of
| help for the game developer, i.e. "intellisense" kind of
| functionality. I've basically "solved" this by assuming that
| variables have certain name suffixes and prefixes and when those
| are present I assume that it has a certain type which lets me
| provide a list of functions in the script editor to the game
| developer. Far from perfect. [see link below]
|
| https://github.com/ensisoft/detonator/blob/master/screens/ed...
| spookie wrote:
| Any alternatives you've tried that are better in those areas?
| augusto-moura wrote:
| The lua language service [1] supports type annotations inside
| comments [2]. Sure, it is not the same as having types as first
| class citizens, but I would say that it solves 95% of the
| editor support and typying problems you mentioned in your 3rd
| point.
|
| But yeah, PUC-Rio Lua is not fast, but it is acceptable, and
| maybe one of the most performant of all non-JIT dynamic
| languages. If you need speed, JIT is a requirement.
|
| [1]: https://luals.github.io/
|
| [2]: https://luals.github.io/wiki/annotations/
| Llamamoe wrote:
| It's a shame you can't use LuaJIT. It's one of if not THE
| highest performance JIT out there.
| nicce wrote:
| What is the usecase for WASM? Browser games?
___________________________________________________________________
(page generated 2025-05-16 23:01 UTC)