[HN Gopher] Luau goes open-source
       ___________________________________________________________________
        
       Luau goes open-source
        
       Author : ingve
       Score  : 193 points
       Date   : 2021-11-03 17:24 UTC (5 hours ago)
        
 (HTM) web link (luau-lang.org)
 (TXT) w3m dump (luau-lang.org)
        
       | VWWHFSfQ wrote:
       | Can this transpile type-annotated Luau code to just regular Lua
       | code? I would like to add type checks to my Lua code but I dont
       | want to run it in the Luau VM. I want to run it in PUC-Rio Lua,
       | and LuaJIT. Something like Haxe[1], but not an entirely different
       | programming language.
       | 
       | [1] https://haxe.org/
        
         | spicybright wrote:
         | I highly doubt it. Most of the time with these forks they
         | change/remove core language features instead of compiling down
         | to plain lua.
        
           | tfsh wrote:
           | It's worth noting that Luau is backwards compatible with Lua
           | 5.1*, so I see no technical reason why transpilation wouldn't
           | be possible.
           | 
           | * I'm tangentially aware of some RFCs to deprecate metatable
           | related methods (setmetatable, getmetatable, rawset, etc),
           | which may have an impact.
        
         | japhib wrote:
         | Doubtful, but there is TypescriptToLua:
         | https://typescripttolua.github.io/
         | 
         | Here's a whole list of languages that compile to Lua (many of
         | them statically typed): https://github.com/hengestone/lua-
         | languages
        
         | implicit wrote:
         | There is a transpiler in the source tree, but I expect it needs
         | a polish pass. We haven't put it to use in quite some time.
         | 
         | In particular, I am pretty sure that it won't do the right
         | thing when it encounters the extra syntax we've added to Luau.
         | So far, that's an if-else expression and a continue keyword.
         | Transpiling those accurately will take a bit of work.
        
         | buybackoff wrote:
         | There is Teal language that has type annotations and could
         | output plain Lua: https://github.com/teal-language/tl
        
           | VWWHFSfQ wrote:
           | ooh neat
        
       | asb wrote:
       | The compatibility page (https://luau-lang.org/compatibility)
       | mentions a "pending GC rework". Does anyone know anything more
       | about this?
       | 
       | I can recommend reading the performance page, it's a an engaging
       | summary of the various tricks/optimisations that have been
       | implemented https://luau-lang.org/performance
        
       | sizediterable wrote:
       | From https://luau-lang.org/typecheck
       | 
       | > Luau's type system is structural by default
       | 
       | I think that makes it the second (production-ready) language to
       | have a primarily-structural type system, after
       | TypeScript/Flow(/and Closure to some extent) for JS. I wonder if
       | it will follow in their impressive footsteps or if it will tread
       | new territory.
       | 
       | One of the things that Flow gets right that TypeScript doesn't
       | yet support is switching to nominal type-checking between class
       | instances. In TypeScript you can assign an instance of one class
       | to an instance of another as long as they have compatible fields.
       | Compare:
       | 
       | Flow: https://bit.ly/3jZx4rB
       | 
       | TS: https://tsplay.dev/mZaL1N
       | 
       | TypeScript doesn't have any understanding of prototypes or
       | prototypal inheritance, which is a big gap considering that it's
       | a fundamental aspect of JS.
       | 
       | I'm really hoping Luau will come to do the right thing with
       | tables and prototypes. Perhaps it already does, but unfortunately
       | there doesn't seem to be a Luau playground to try in the browser.
        
         | implicit wrote:
         | Luau already has some notion of nominal types to deal with the
         | fact that the Roblox API is basically a ton of C++ classes that
         | have been mapped over via the FFI. Some of these types are
         | totally structurally identical and yet incompatible.
         | 
         | We'd like to afford the same kind of ideas for native Luau
         | code, but we're not there yet.
        
         | [deleted]
        
         | IshKebab wrote:
         | > a big gap considering that it's a fundamental aspect of JS.
         | 
         | To be fair to Typescript, it's an insane fundamental aspect of
         | JS.
        
           | Zababa wrote:
           | Funny that you would mention that in a thread on a
           | statically-typed language based on Lua. Don't you need some
           | insane mechanism to be flexible at runtime anyways? Either it
           | will be reflection, or something like prototypes (in OO
           | languages).
        
         | dgb23 wrote:
         | What about Go and OCaml? And I'm sure there are others.
        
           | Zababa wrote:
           | I think OCaml isn't just structural. For example, sum types
           | (variants in OCaml) have a nominal form which is the default:
           | https://ocaml.org/manual/coreexamples.html#s%3Atut-
           | recvarian..., but also a structural form, polymorphic
           | variants: https://ocaml.org/manual/polyvariant.html. I think
           | it's the same for records, I didn't find a way to express the
           | type "a record that has a certain field" as an argument of a
           | function. You can do this with objects and modules I think,
           | but not with records.
        
           | sizediterable wrote:
           | I forgot about OCaml (since I normally associate it with the
           | more sophisticated typing stuff). I don't know if I'd
           | completely count Go since interfaces only apply to methods,
           | not fields
        
             | dgb23 wrote:
             | Disclaimer: Not a regular Go user.
             | 
             | I was thinking of how you can embed types in structs. You
             | automatically dereference the fields and methods of the
             | components directly from the outside.
        
         | wwwigham wrote:
         | > In TypeScript you can assign an instance of one class to an
         | instance of another as long as they have compatible fields.
         | 
         | Fun fact: If you add a private field to a class it'll behave
         | nominally in TS. This is because private fields kinda require
         | nominal relations to function. So, in a way, it does support
         | "switching" to nominal type checking for classes - the opt in
         | is simply per-class.
        
           | mirekrusin wrote:
           | It won't do variance [0] right, will it?
           | 
           | [0] https://flow.org/en/docs/lang/variance/
        
             | sizediterable wrote:
             | I think variance can be simulated by typing the private
             | field as an existing covariant/contravariant/invariant type
             | class CovariantFoo<T> {         private phantom!: T       }
             | class ContravariantFoo<T> {         private phantom!: (_:
             | T) => void       }            class InvariantFoo<T> {
             | private phantom!: (_: T) => T       }
             | 
             | (inspired by Rust [0])
             | 
             | [0] https://doc.rust-lang.org/nomicon/phantom-data.html
        
               | mirekrusin wrote:
               | But variance depends on position where the value is used,
               | not at the time of declaration, superclass/subclass at
               | parameter/return value position can't be correctly
               | encoded like this, can it?
        
               | sizediterable wrote:
               | I think most languages define variance at type definition
               | level, notable exceptions being Kotlin which supports
               | both [0][1] and Flow. But yeah, TS doesn't support
               | (variable-)declaration-site variance which I didn't
               | realize you were asking in my previous answer.
               | 
               | [0] https://kotlinlang.org/docs/generics.html#variance
               | 
               | [1]
               | https://kotlinlang.org/docs/generics.html#declaration-
               | site-v...
        
               | mirekrusin wrote:
               | Doesn't OCaml support it as well?
        
               | sizediterable wrote:
               | I'm less familiar with OCaml and don't know off the top
               | of my head. Doing a quick search I was only able to find
               | references to type declaration variance [0], though I
               | learned that Java also supports use-site variance too [1]
               | 
               | [0] https://blog.janestreet.com/a-and-a/
               | 
               | [1] https://blog.jooq.org/tag/use-site-variance/
        
           | sizediterable wrote:
           | Oh cool, hadn't realized this. Also thanks for your great
           | work! I'm rooting for some of your exploratory PRs!
        
       | Rochus wrote:
       | > _If you wear a grass skirt and lei, you will most likely fit in
       | at a luau._
       | 
       | https://www.vocabulary.com/dictionary/luau,
       | https://en.wikipedia.org/wiki/L%C5%AB%CA%BBau
        
         | allknowingfrog wrote:
         | Thank you for this. I kept trying to pronounce this as some
         | combination of "lua" and a "u" sound, which made no kind of
         | sense. I have apparently never seen the word "luau" out of
         | context.
        
       | junon wrote:
       | If any of the Luau devs are watching this, _please_ flesh out the
       | metamethods. I 'd switch almost everything to Luau if they were
       | improved.
       | 
       | They're the biggest PITA right now as designed in PUC-Rio, and I
       | see that while you've improved upon __eq, other metamethods are
       | still lacking.
       | 
       | In PUC-Rio, boolean equality operators FORCE a boolean result,
       | regardless of what you return. Ideally they would allow returning
       | _any_ result type, which then can be coerced to boolean later
       | (e.g. by an `if` statement), just like the arithmetic operators
       | do.
       | 
       | Further, `__neq`, `__ge` and `__gt` do not exist. They should.
       | 
       | The lack of a proper metamethod design means that binding to e.g.
       | Kiwi[0] is impossible without some incredibly fugly hacks. It has
       | been a long-standing annoyance with Lua in an otherwise beautiful
       | little scripting language (that I use _frequently_ ).
       | 
       | This looks quite nice - lots of attempts in this space but
       | nothing that attempts to match Lua to this degree.
       | 
       | [0] https://github.com/nucleic/kiwi
        
         | [deleted]
        
         | [deleted]
        
         | junon wrote:
         | Actually went ahead and wrote an RFC for this:
         | https://github.com/Roblox/luau/pull/109
        
       | vanderZwan wrote:
       | > _using a combination of techniques pioneered by LuaJIT and
       | custom optimizations that are able to improve performance by
       | taking control over the entire stack (language, compiler,
       | interpreter, virtual machine), we're able to get close to LuaJIT
       | interpreter performance while using C as an implementation
       | language._
       | 
       | At first I was a bit surprised by this, given that they have much
       | better type information, but they forget to mention until further
       | on that Luau doesn't use JIT/AOT optimizations (yet). Still, it's
       | as good an excuse as any to bring out this quote again:
       | 
       |  _"LuaJIT is much faster than all of the other languages,
       | including Wren, because Mike Pall is a robot from the future"_
       | 
       | - Robert Nystrom
        
         | VWWHFSfQ wrote:
         | LuaJIT is truly a marvel of engineering. I put it on par with
         | the JVM itself in terms of things that I'm just completely
         | blown away by.
        
         | arthurcolle wrote:
         | People seem to say this (or similar remarks) when talking about
         | Lua but even more specifically, LuaJIT in particular but it
         | seems like Lua is already a pretty niche language so am I just
         | missing something? Like you can embed Lua in other languages
         | but why use Lua instead of something like mruby for all the
         | warm fuzzy feelings you get when writing Ruby?
         | 
         | Just curious, appreciate any context you can provide!
        
           | stravant wrote:
           | The advantage that Lua has is that it has about the simplest
           | possible binding interface you can imagine for a Language.
           | 
           | There's no manifests, no class definitions, no anything
           | really. It's as simple as calling lua_newstate to create a
           | state, calling lua_pushcfunction to register some functions
           | that expose your desired engine functionality, and calling
           | lua_loadstring with a script to run.
           | 
           | That means you can use Lua in your engine for something as
           | simple as a CLI interface that just exposes a couple dozen
           | functions, and it's still worth it. Where with any other
           | scripting language you'd have to be doing a lot more with it
           | to make the setup cost worthwhile.
           | 
           | Having LuaJIT available if you end up wanting to do more with
           | it later is the icing on the cake.
        
           | pansa2 wrote:
           | > _why use Lua instead of something like mruby_
           | 
           | The main reason is momentum - Lua has been the de-facto
           | standard embeddable language for at least 15 years. For
           | example, it's used in World of Warcraft which was released in
           | 2004.
           | 
           | Another reason is the quality of the implementation - Lua has
           | very few bugs [0], whereas Shopify tried to embed mruby and
           | had to give up because it had too many security holes [1].
           | 
           | Finally, Lua is a complete language in itself, with a
           | guidebook, reference manual and so on. Mruby (and
           | MicroPython) are less well-known. Plenty of people know Ruby
           | or Python, but if you use the smaller implementations, you
           | never know when your code might hit a language feature that
           | they don't support.
           | 
           | [0] https://www.lua.org/bugs.html [1]
           | https://brandur.org/fragments/shopify-mruby
        
         | [deleted]
        
         | klelatti wrote:
         | Slight digression. IIRC PHP was using Mike's work (DynASM) a
         | while ago. Is this still the case and is anyone else using
         | aspects of LuaJIT (eg DynASM or the byte code interpreter)?
        
       | mid-kid wrote:
       | I'm mostly wondering, what does this have over regular Lua,
       | especially now with 5.4?
        
         | plorkyeran wrote:
         | Type annotations are the main benefit. It's also much faster
         | than Lua 5.1, but I don't know how it compares to 5.4.
        
           | jay_kyburz wrote:
           | I really miss compound assignments and a continue statement.
           | The if then else expressions look cool too.
           | 
           | Would love to see these in the LuaJIT but I think its
           | considered "done"
        
         | krinchan wrote:
         | Lua's biggest thing is that it's pretty easy to embed inside a
         | C/C++ application safely, for relative definitions of "safe"
         | spanning "preventing the Lua code from segfaulting your
         | application" to "preventing the Lua code from doing anything
         | you don't explicitly give it the ability to do".
         | 
         | It's why you see it used as so many game's plugin architecture
         | and why it was selected for NeoVim.
         | 
         | So there is a very large ecosystem of Lua code that just lives
         | in Lua 5.1 and doesn't really push forward at all. I haven't
         | checked in on the situation for some time, but most people who
         | write Lua are writing Lua for something like NeoVim or WoW or
         | some other plugin for a larger project. Those projects have no
         | interest in dealing with the slow reference VM for Lua >=5.2 at
         | this time.
         | 
         | Lua 5.2, 5.3, and 5.4 are more analogous to Python 2 to Python
         | 3's level of change, rather than Python 3.9 to Python 3.10.
         | These more recent versions of Lua 5.x are somewhat incompatible
         | with each other, rather than just adding new language features.
         | 
         | Most products settle on Lua 5.1 because that is what luajit, a
         | very fast just in time compiling implementation of the Lua VM
         | supports. Plans to further support to new versions for luajit
         | are...well they exist.
        
           | pansa2 wrote:
           | > _WoW [...] have no interest in dealing with the slow
           | reference VM_
           | 
           | Does WoW use LuaJIT? I thought it used the reference Lua 5.1
           | VM, simply because that was the newest version when it was
           | first released.
           | 
           | > _Plans to further support to new versions for luajit
           | are...well they exist._
           | 
           | I'm not sure it'll ever happen. AFAICT LuaJIT is so complex
           | that only its author, Mike Pall, understands it well enough
           | to make major changes. He has expressed his dislike for
           | several of the changes in Lua >= 5.2.
        
         | ketralnis wrote:
         | I can tell you from my own experience that luajit, which also
         | targets 5.1 compatibility, is _significantly_ faster than Lua
         | proper. In using it I've never missed 5.2+ features. So I
         | imagine luau has the same thing going for it.
        
           | [deleted]
        
           | pansa2 wrote:
           | I would expect Luau to be significantly slower than LuaJIT
           | though, because Luau doesn't include a JIT compiler.
        
             | dangoor wrote:
             | True, but they claim to have gotten as fast as LuaJIT in
             | many cases and, important for their use case, JIT doesn't
             | work on some platforms (iOS): https://luau-
             | lang.org/performance
             | 
             | > On some workloads it can match the performance of LuaJIT
             | interpreter which is written in highly specialized
             | assembly.
        
               | dirkf wrote:
               | Note how it says: "match the performance of the LuaJIT
               | _interpreter_ " (emphasis mine). LuaJIT basically has two
               | parts: an interpreter in handcrafted assembly which is
               | quite a bit faster than the standard Lua VM, and the
               | actual JIT, which is even faster. IIRC on iOS the JIT is
               | not allowed but the interpreter is still there.
        
         | [deleted]
        
       | ttymck wrote:
       | The more I read about Lua, the more I like it. What's the
       | recommended learning material for beginners?
        
         | VWWHFSfQ wrote:
         | Programming in Lua[1] is the K&R for Lua.
         | 
         | [1] https://www.lua.org/pil/
        
       | losvedir wrote:
       | Who needs yet another progra.... oh, it's a gradually typed fork
       | of Lua in production use at Roblox _eyes slowly widen_.
        
         | [deleted]
        
       | spicybright wrote:
       | Heck yeah.
       | 
       | I don't know what this fork changes, but I love how many game
       | engines will take lua and expand it to fit their exact needs like
       | this.
       | 
       | Very few scripting languages make it as easy to do as lua.
       | 
       | This is an interesting related project:
       | 
       | https://moonscript.org/
       | 
       | It compiles down to lua, and really beefs everything up.
       | Interface is super nice too. You just put `require "moonscript"`
       | at the top of the file and you're done, now just write your code
       | in moon script.
        
         | xvilka wrote:
         | There is also a Fennel[1] that builds a LISP on top of Lua.
         | 
         | [1] https://fennel-lang.org/
        
         | MaximumADHD wrote:
         | To my understanding it's not so much a fork of Lua as it is a
         | complete rewrite in C++. They've created their own custom VM
         | and everything. The closest version it has parity with is Lua
         | 5.1.4, with a few compatible features from 5.2 and 5.3
         | backported.
        
           | spicybright wrote:
           | Wow, now that's even more impressive.
           | 
           | Makes me wonder if there's anything useful to "upstream" to
           | vanilla lua here, or if the VM deviated too far.
        
             | kzrdude wrote:
             | PUC-Rio's Lua doesn't take contributions anyway, right?
             | It's open source but it's not an open project. Similar to..
             | uh.. nethack, at least how it used to be :)
             | 
             | https://www.lua.org/community.html
        
       | disjukr wrote:
       | There is a language [1] that type check by adding comments
       | instead of fixing Lua (like Flow comment syntax [2]), I wonder if
       | the Luau team has considered this language.
       | 
       | [1] https://github.com/devcat-studio/kailua
       | 
       | [2] https://flow.org/blog/2015/02/20/Flow-Comments/
        
       ___________________________________________________________________
       (page generated 2021-11-03 23:00 UTC)