5 ms·
Show HN: LadyLua, batteries-included static Lua 5.1 interpreter
- Evidlo 5y agoI think the readme could use some examples of where this might be useful
- Propolice 5y agoHello, 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?
- andi999 5y agoIs there a numpy binding?
- Propolice 5y agoAh sorry for mentioning Python, may have confused you. LadyLua wraps Go packages so something like https://github.com/gonum/gonum https://github.com/gonum/gonum is possible to create a module for.
- Evidlo 5y agoIf this is to replace shell scripts, then some justification or examples to why would this is an improvement would be nice.
- Propolice 5y agoYes, can be used to replace shell scripts. I added a Sample section in the README. Check em.
- marktangotango 5y agoNice 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 https://pkg.go.dev/github.com/aarzilli/golua/lua
- pansa2 5y agoGopherLua [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 https://github.com/yuin/gopher-lua [1] https://github.com/Shopify/go-lua https://github.com/Shopify/go-lua [2] https://github.com/Azure/golua https://github.com/Azure/golua
- chgibb 5y agoThis 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 5y agoLua 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 5y ago> 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 5y agoDo 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 http://www.lua.org/manual/5.2/manual.html#8 [2] http://www.lua.org/manual/5.3/manual.html#8 http://www.lua.org/manual/5.3/manual.html#8
- BugsJustFindMe 5y agoIt's a real shame to pin to Lua 5.1 but not use LuaJIT.
- Propolice 5y agoI have an earlier project that did LuaJIT, FFI, and Rust: https://github.com/tongson/omniajit 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_duke 5y agoGo 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 5y agoYes, 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.
- ampdepolymerase 5y agoIf 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.
- pjmlp 5y agoGo has all the required primitives, unsafe and assembler as part of the toolchain.
- the_hoser 5y agoThis 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 5y agoI'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 5y agoNeat. I'll try to remember that the next time I need to work with Lua.