1. 25
  1.  

  2. 4

    It’s a bummer that most of the Lua ecosystem is stuck on 5.1 due to LuaJIT compatibility.

    1. 1

      Would you happen to know if there is any particular reason for this?? Apart from lack of time.

      1. 1

        My high-level understanding is the implementation of how integers were added in 5.3 conflicts with some of the optimizations LuaJIT does. (Also “lack of time” is a bit of an oversimplification; Mike Pall, the superhero genius author of LuaJIT is retired and there’s only one or two other humans on the planet as smart as he is.)

        1. 1

          it’s a shame I really like the focus on minimalism. Seems like the javascript hipsters that dominates the current generation never have seen a modem. I find the wastefulness of much of modern tools to be distasteful. lua is one of the best arguments that you can achieve a lot with very little.

          Beutifully designed and fun language as well. It’s a shame to hear of the state of luajit as JIT really is necessery for the language to compete.

          1. 5

            The default interpreter is also fast (faster than Python or Ruby) and I’m using it successfully at work to parse SIP messages (well, Lua and LPEG) in real time.

        2. 1

          It’s largely due to Mike Pall (creator of LuaJIT) having a fundamental disagreement with how globals are handled in Lua 5.2 and above—the entire mechanism changed (and it affected how modules are written as well). In Lua 5.1, globals are stored in a table associated with a function (its so called “environment”), and there were two functions to manipulate this (getfenv() and setfenv() in Lua; lua_getfenv() and lua_setfenv() from C). This changed in Lua 5.2 to a local variable (technically, an “upvalue”) holding the global variables (by the name of _ENV). It may have been too much of a change to deal with it properly in LuaJIT, I don’t know as I haven’t looked into the guts of it.

        3. 1

          Why do you think this is a “bummer”? Lua 5.1 is perfectly capable, 5.2-3 have had very minor changes (unless it was something you really cared about like an integer type).

          Granted a generational gc could be significant for long running scripts, but my impression is most lua usage is not long running scripts. That’s my impression at least.

          1. 2

            How modules work is a bit more than “very minor change” so at the time, I didn’t feel any compelling reason to even use Lua 5.2. Lua 5.3 introduced 64-bit integers and byte packing functions that were compelling enough to switch to (plus a UTF-8 module and built in boolean operators). There are some minor annoyances to deal with (mainly around module definitions and some C API changes) but I was able to get the modules I’ve written to work with Lua 5.1 through Lua 5.3 (I’m still waiting for the official release of Lua 5.4 before updating my modules).

            1. 1

              It’s not that bad but it makes more work for people who write libraries for Lua. Currently most libs support both 5.1 and 5.3. There is even library that helps in writing compatible code. It will just get harder with every breaking change in Lua.

              1. 1

                my impression is most lua usage is not long running scripts.

                Isn’t this a bit of a circular argument? Lua isn’t used for long-running scripts because its GC isn’t that good; Lua doesn’t need a good GC because it’s not used for long-running scripts.

                1. 3

                  We use long running Lua based (5.1) programs at work and we’ve had no issues with the GC. And by “long running” I mean “around six months or so between deployments [1].”

                  [1] Due to several factors we don’t move fast and break things—the SLAs and updating procedures we have with the Monopolistic Phone Company precludes doing that.

            2. 3

              The changelog doesn’t read hugely exciting. Perhaps the new garbage collector is important?

              • new generational mode for garbage collection
              • to-be-closed variables
              • const variables
              • userdata can have multiple user values
              • new implementation for math.random
              • warning system
              • debug information about function arguments and returns
              • new semantics for the integer ‘for’ loop
              • optional ‘init’ argument to ‘string.gmatch’
              • new functions ‘lua_resetthread’ and ‘coroutine.kill’
              • coersions string->number moved to the string library
              • allocation function allowed to fail when shrinking a memory block
              • new format ‘%p’ in ‘string.format’
              • utf8 library accepts codepoints up to 2^31
              1. 4

                Const variables are a pretty big change in my eyes. I’m not sure what a to-be-closed variable is.

                1. 9

                  The docs

                  A to-be-closed variable behaves like a constant local variable, except that its value is closed whenever the variable goes out of scope, including normal block termination, exiting its block by break/goto/return, or exiting by an error.

                  Here, to close a value means to call its __close metamethod. If the value is nil, it is ignored; otherwise, if it does not have a __close metamethod, an error is raised. When calling the metamethod, the value itself is passed as the first argument and the error object (if any) is passed as a second argument; if there was no error, the second argument is nil.

                  1. 1

                    D’oh. Thanks.

                    I guess it’s used for:

                    local <toclose> f = io.open('file.txt', 'r')
                    local contents = f:read('*a')
                    

                    I don’t see how that’s any better than:

                    local f = io.open('file.txt', 'r')
                    local contents = f:read('*a')
                    f:close()
                    

                    Weird feature.

                    1. 8

                      I think difference is, you do not have to call :close. Why is it important, because in complex nested/multi-if statements you do not need to cover each path of block’s scope exit.

                      Seems similar how one would do a deterministic resource management in C++.

                      1. 1

                        Yeah like I said it’s a weird feature. Not very Lua-like if you ask me.

                      2. 4

                        It’s the same as defer in Go it seems.

                        1. 2

                          Except without the weird thing where it’s done as a separate fundamental piece of syntax instead of being integrated gracefully with existing language mechanisms.

                          1. 1

                            Umm, but <toclose> also seems to be kinda new, separate fundamental piece of syntax, no? :) I don’t remember seeing it in previous versions of Lua…

                            1. 1

                              Oh, I misread it as being an example notation similar to $VAR but I see you’re right. It’s just a new kind of identifier instead of changing existing rules for how evaluation happens, so I would say it’s a much simpler extension, but yeah it is new syntax.

                            2. 1

                              Yes but take into account that Lua was first released in 1994, that’s around 20 years before go. Probably doesn’t make very much sense for them to redefine it at a fundamental level.

                              1. 2

                                Lua was first released in 1994, that’s around 20 years before go.

                                Obligatory, “despite being released so recently, Go feels like it came from the 70s.”

                                1. 1

                                  The heyday of it’s creators some things I do like I’m go others feels silly. Lua on the other hand have really nice concepts, is light and is just so much fun to code in. Trapped in js for the time being though but only since I want to Target web.

                                  1. 1

                                    Trapped in js for the time being though but only since I want to Target web.

                                    Obligatory plug for https://fengari.io/

                                    1. 2

                                      I see from your blog thatt you’ve used löve framework, I’ve had so much fun with that one.

                                      Have you worked on used fengari.io for any projects?

                                      1. 1

                                        Yes, although my code is rather simple.

                                        The live in-browser repl on https://fennel-lang.org uses Fengari. I haven’t done any Javascript since 2005 or so, but I was able to easily and quickly integrate Fengari’s Lua VM into the page I had built and plug the Fennel repl directly into an <input> element; it worked much better than I had expected. The developer was very responsive and supportive too.

                                        https://git.sr.ht/~technomancy/fennel-lang.org/tree/master/repl.fnl

                                        ^ I’m using coroutines to create an interactive repl tutorial that proceeds thru a series of steps as the user enters input.

                                        1. 2

                                          hm very clever! I couldn’t help to notice from your webpage that you are creating keyboards as well, how is that going?

                                          1. 1

                                            It’s great; lots of fun to build things with your hands. I’m speaking on the topic at RacketCon in July: https://con.racket-lang.org/#speakers

                                            Feel free to message me if you have any questions about the kit.

                                            1. 2

                                              Sounds interesting no way I’ll make it to salt lake City until then though!!

                                2. 2

                                  I guess I was a bit unclear; I’m saying introducing separate syntax for something that can be cleanly expressed using existing syntax is tacky as hell; and I’m somewhat baffled why defer in golang was done the way it was. Lua’s way makes way more sense.

                                  1. 1

                                    ah I understand! Thanks for the clarification

                            3. 2

                              The feature is useful in case f:read() raises an error.

                        2. 2

                          Why change a winning concept? Would love to have more details on the garbage collector but dont have the time to research