1. 32

The Hacker News thread has people involved commenting that the goal is to use it in Helm.

  1.  

  2. 10

    See also: https://github.com/Shopify/go-lua (5.2) and https://github.com/yuin/gopher-lua (5.1)

    Gotta catch ’em all?

    1. 4

      Interestingly, when I once tried to do a Lua port to Go (before gopher-lua etc.; I tried to use c2go to make it automatic), I noticed that Go and Lua have a lot in common (a lot of similar decisions/convergent evolution). To the extent that I got into kinda “uncanny valley” state after writing snippets of Lua in Go, where I was so confused which one I’m writing, that I constantly did some stupid mixing errors… and couldn’t force myself to just stay in one of them… it was very weird :)

      1. 5

        So go implementation of Lua used to script Helm to control Kubernetes to distribute containers to virtual machines that will execute the applications inside the containers within jails. dizzying.

        1. 2

          What’s wrong with current’s implementation written in ANSI C? Seems like a waste of human resources, in my opinion.

          1. 32

            What’s wrong with current’s implementation written in ANSI C?

            If you want to script a Go application, it’s a hell of a lot easier if the VM is native instead of trying to fight with C interop issues.

            Seems like a waste of human resources, in my opinion.

            Incredible that with zero insight into the business requirements or technical motivations behind a project, you still consider yourself qualified to judge the staffing allocations behind it

            1. 7

              Incredible that with zero insight into the business requirements or technical motivations behind a project, you still consider yourself qualified to judge the staffing allocations behind it.

              You are definitely right about this.

              If you want to script a Go application, it’s a hell of a lot easier if the VM is native instead of trying to fight with C interop issues.

              As @tedu commented, I understand the motivation behind it, thanks for pointing it out too.

              1. 2

                They give some further explanation of the technical requirements that led them not to pick up Shopify’s version here, which I found intersting: https://github.com/Azure/golua/issues/36.

                The TL;DR is they’ve been scripting Helm for a while using another Lua-in-Go engine, but it isn’t updating to 5.3, which they very much want, along with closer conformance to the Lua spec, plus they have some design ideas that they feel would make debugging etc easier.

                1. 3

                  To each their own, but I’m a little perplexed that strict 5.3 conformance would be a driver. I’m using gopher-lua which is like 5.1 but not exactly, but it’s just fine. What I need is some scripting language to embed, it’s close enough to lua it’s not really learning a whole new whatever, and it interfaces nicely with go (nicer than a strict port of the stack api would).

                  I don’t know jack about helm, but after seven seconds of research I can’t reverse engineer a requirement for lua 5.3 accept no substitutes.

                  1. 1

                    It’s possible that they have some need of true 64-bit integers, which only came to Lua in 5.3. That’s the only important change I can think of.

            2. 5

              Writing memory-safe C is an artform and a craft.

              Writing safe code with Go is something a trained orangutang can do.

              1. 3

                Lua bytecode is memory-unsafe in the reference implementation, for starters.

                1. 2

                  Do you have a link or more details?

                  1. 1

                    My upload server was down, sorry I didn’t link this originally. Here’s a slide deck (pdf) of a presentation I gave at Houston Area Hackers with almost all the details you could want.

                    I still have to update this; there are quite a few more tricks you can pull. I ended up creating a pure-Lua dlsym() implementation for the project that spurred all this research.

                    1. 2

                      Hmmm… Do reimplementations like this one remove support for lightuserdata then? I’m having a hard time imagining a lua interpreter for arbitrary bytecode that supported lightuserdata but could nevertheless guarantee that those pointers were safe.

                      1. 1

                        Yeah. In gopher-lua, userdata actually looks kind of like lightuserdata, which doesn’t exist. When both host and lua state share an allocator, the difference becomes less meaningful.

                        1. 1

                          Looks like it’s unimplemented. lightuserdata is a pretty damn leaky Lua API. Bytecode itself is even more leaky in the Lua C implementation - arbitrary Lua bytecode is as expressive as C. No surprise that MS seemingly wanted to make an API/ABI compatible implementation that fixed some unnecessary leakiness.

                  2. 2

                    It’s annoying to interface with from go code.

                    1. 1

                      seems like something that should be fixed in Go rather than reimplementing everything written in C.

                      1. 1

                        For better or worse, it’s a result of deliberate design trade-offs in go, so it’s unlikely to change.