[HN Gopher] Show HN: LadyLua, batteries-included static Lua 5.1 ...
       ___________________________________________________________________
        
       Show HN: LadyLua, batteries-included static Lua 5.1 interpreter
        
       Author : Propolice
       Score  : 59 points
       Date   : 2021-04-08 12:43 UTC (10 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | marktangotango wrote:
       | Nice effort, my main question is why not the "standard" go lua
       | wrapper, golua[1]? More specifically, why implement a lua
       | interpreter in go, when there is a perfectly useable c-api
       | wrapper for go?
       | 
       | [1] https://pkg.go.dev/github.com/aarzilli/golua/lua
        
         | pansa2 wrote:
         | GopherLua [0] is a Lua implementation written in Go, not just a
         | wrapper around the reference implementation (written in C). The
         | main alternative seems to be Shopify's go-lua [1], given that
         | Microsoft's golua [2] is no longer being developed.
         | 
         | The main difference between these three implementations seems
         | to be the supported Lua version - 5.1, 5.2 and 5.3
         | respectively. Of course, the reference implementation is now on
         | version 5.4 - these are all considered different major versions
         | of the language (Lua doesn't use SemVer).
         | 
         | [0] https://github.com/yuin/gopher-lua
         | 
         | [1] https://github.com/Shopify/go-lua
         | 
         | [2] https://github.com/Azure/golua
        
       | Evidlo wrote:
       | I think the readme could use some examples of where this might be
       | useful
        
         | Propolice wrote:
         | Hello, instead of like, Python you would reach for this
         | instead. Already able to replace whole shell scripts with this.
         | What would you like to see? Snippets?
        
           | Evidlo wrote:
           | If this is to replace shell scripts, then some justification
           | or examples to why would this is an improvement would be
           | nice.
        
           | andi999 wrote:
           | Is there a numpy binding?
        
             | Propolice wrote:
             | Ah sorry for mentioning Python, may have confused you.
             | 
             | LadyLua wraps Go packages so something like
             | https://github.com/gonum/gonum is possible to create a
             | module for.
        
               | egeozcan wrote:
               | Sorry for bombarding you with questions, I really
               | appreciate the great work!
               | 
               | Is there any docs on how to achieve that?
        
               | Propolice wrote:
               | Sorry no docs right now. You can take a look at this to
               | get a feel: https://github.com/layeh/gopher-json
        
       | BugsJustFindMe wrote:
       | It's a real shame to pin to Lua 5.1 but not use LuaJIT.
        
         | Propolice wrote:
         | I have an earlier project that did LuaJIT, FFI, and Rust:
         | https://github.com/tongson/omniajit. Creating a static
         | executable is more trouble compared to LadyLua. I would still
         | use it for anything that needs less resources and speed.
        
       | the_hoser wrote:
       | This doesn't appear to really do anything to address the one big
       | problem I've had with using Lua for larger applications. Does
       | GopherLua still have global-by-default variables?
        
         | samatman wrote:
         | I've found this to be completely solved by using the strict
         | mode provided by penlight.
         | 
         | It becomes a shallow runtime bug, so it isn't a compiler
         | failure. But I've literally never had a misspelled global stick
         | around for long enough to qualify as a "bug" rather than a
         | mistake. I have polluted the global namespace once or twice by
         | assigning to a new misspelled global in the outermost chunk,
         | which is a little more bugesque, but very seldom.
        
           | the_hoser wrote:
           | Neat. I'll try to remember that the next time I need to work
           | with Lua.
        
       | chgibb wrote:
       | This is really cool!
       | 
       | Why Lua 5.1 and not 5.2 or 5.3? What does the marshalling story
       | between Lua and the builtin Go modules look like? What would it
       | take to add more builtins or richer marshalling?
       | 
       | I love seeing other Lua implementations.
        
         | ronsor wrote:
         | Lua 5.1 likely still is the most widely-supported version by
         | scripts (and though irrelevant in this context, external native
         | libraries). Remember that LuaJIT is also Lua 5.1 compatible.
        
         | lifthrasiir wrote:
         | > Why Lua 5.1 and not 5.2 or 5.3?
         | 
         | Each version of Lua since 5.1 is basically equivalent to Python
         | 2 and 3, subtly different enough that you have no clear
         | migration path. (And worse, Lua didn't even have an equivalent
         | to 2to3.) So many applications are stuck at 5.1.
         | 
         | I think that there is a decent chance for other implementations
         | to overtake PUC-Rio Lua if this missing migration path is
         | clearly laid. The starter would be implementing all versions at
         | once and allowing the mix of codes written for different
         | versions.
        
           | gnramires wrote:
           | Do note that Lua is a quite small and simple language. While
           | the difference in internals are significant (hence LuaJIT
           | staying on 5.1), in terms of usage it's just a handful of
           | changes (see here [1] and [2]). The difference with python is
           | that they are not backwards compatible, so even if they're
           | small they might break projects.
           | 
           | This is a double-edged sword, it allows unashamed
           | modifications but it does require rewrites.
           | 
           | Hopefully things settle with 5.4. I love how small and
           | comprehensible the language is.
           | 
           | > The starter would be implementing all versions at once and
           | allowing the mix of codes written for different versions.
           | 
           | I don't think this is quite possible, because some formatting
           | and function return minor details that changed that would
           | break interoperability. That said, porting between versions
           | shouldn't be difficult. Just using the latest version would
           | be the easier and safer solution.
           | 
           | [1] http://www.lua.org/manual/5.2/manual.html#8
           | 
           | [2] http://www.lua.org/manual/5.3/manual.html#8
        
         | Propolice wrote:
         | LadyLua is using GopherLua as the base. It only supports 5.1.
         | Also don't need the features of 5.2+. Sticking with 5.1 gets
         | you a 'finished' language.
         | 
         | GopherLua <-> Go is pretty easy. I was doing LuaJIT FFI to Rust
         | before, moved to GopherLua, it's easier. Check this out to get
         | a feel, it's the json module in LadyLua:
         | https://github.com/layeh/gopher-json
        
       | the_duke wrote:
       | Go seems like a suboptimal language for implementing an
       | interpreter, since it lacks the low level primitives to make a
       | fast interpreter loop.
       | 
       | But I guess, as will all things Go, that it will be fast enough
       | for a good amount of use cases, and having a language native
       | dependency rather than messing with C libraries is always a plus.
        
         | Propolice wrote:
         | Yes, Go is fast enough for some tasks.
         | 
         | Before this I was doing C and PUC-Rio Lua. Was obsessing too
         | much with C pitfalls, valgrind, and the sanitizers. Then LuaJIT
         | FFI + Rust, good I like it better but found GopherLua the
         | easiest. I'd stick with LuaJIT+Rust for anything that needs
         | less resources and speed.
        
         | pjmlp wrote:
         | Go has all the required primitives, unsafe and assembler as
         | part of the toolchain.
        
         | ampdepolymerase wrote:
         | If he really wanted to, he could have written it as a JIT and
         | generate ASM directly. Writing an executable page is quite
         | trivial in Go.
        
       ___________________________________________________________________
       (page generated 2021-04-08 23:01 UTC)