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?
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).
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?
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.
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.
> While the difference in internals are significant (hence LuaJIT staying on 5.1), in terms of usage it's just a handful of changes.
Lua doesn't care about older versions for migration, so its changes tend to be more impactful than it looks. If you write a new code for newer versions you don't need to relearn or unlearn much, but for example `0x7fffffffffffffff + 1` was 9.2233720368548e+18 before Lua 5.3 and is now -1. Can you guarantee that your code is free of such overflows? Can you find all overflows before the migration? This very issue prevented me and my team from migrating to 5.3.
LuaJIT is a different situation by the way, AFAIK it stayed with 5.1 because it allows for more efficient implementation. Mike Pall does share some of my criticisms to Lua as well [1].
> Can you guarantee that your code is free of such overflows?
Well, according to the manual, you can by appending '+0.0' (or '.0'?) to numbers, converting it to float (tested on Lua 5.4 even hex '0xf...f' can be written as '0xf...f.0').
I don't quite understand the change in terms of language design -- if integer was necessary surely an integer library would be sufficient? I find it a little "too smart for its own good" (in the sense of being unreliable in practice). Perhaps they could have gone for a more separate integer type? For my use cases however, I don't expect to run into any problems (9.2e18 is a very large number).
> Mike Pall does share some of my criticisms to Lua as well [1].
Yes, it makes me sad they broke compatibility so much. I mean, 4 different versions in use is a lot. Hopefully 5.4 is stable now.
> Well, according to the manual, you can by appending '+0.0' (or '.0'?) to numbers, converting it to float.
In addition to making extensive changes to the code, this is not complete because there are plenty of functions that would return integer instead of numbers (e.g. tonumber).
> Perhaps they could have gone for a more separate integer type?
I too think JS did the right thing: it introduced a new type for integers, and took it as a chance to make it arbitrary precision.
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.
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
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.
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.
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?
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?
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.
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.
[1] https://pkg.go.dev/github.com/aarzilli/golua/lua
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
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.
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.
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
Lua doesn't care about older versions for migration, so its changes tend to be more impactful than it looks. If you write a new code for newer versions you don't need to relearn or unlearn much, but for example `0x7fffffffffffffff + 1` was 9.2233720368548e+18 before Lua 5.3 and is now -1. Can you guarantee that your code is free of such overflows? Can you find all overflows before the migration? This very issue prevented me and my team from migrating to 5.3.
LuaJIT is a different situation by the way, AFAIK it stayed with 5.1 because it allows for more efficient implementation. Mike Pall does share some of my criticisms to Lua as well [1].
[1] For example, http://lua-users.org/lists/lua-l/2011-10/msg00578.html or https://www.freelists.org/post/luajit/Port-bitop-to-53,1
Well, according to the manual, you can by appending '+0.0' (or '.0'?) to numbers, converting it to float (tested on Lua 5.4 even hex '0xf...f' can be written as '0xf...f.0').
I don't quite understand the change in terms of language design -- if integer was necessary surely an integer library would be sufficient? I find it a little "too smart for its own good" (in the sense of being unreliable in practice). Perhaps they could have gone for a more separate integer type? For my use cases however, I don't expect to run into any problems (9.2e18 is a very large number).
> Mike Pall does share some of my criticisms to Lua as well [1].
Yes, it makes me sad they broke compatibility so much. I mean, 4 different versions in use is a lot. Hopefully 5.4 is stable now.
In addition to making extensive changes to the code, this is not complete because there are plenty of functions that would return integer instead of numbers (e.g. tonumber).
> Perhaps they could have gone for a more separate integer type?
I too think JS did the right thing: it introduced a new type for integers, and took it as a chance to make it arbitrary precision.
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
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.
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.
LadyLua wraps Go packages so something like https://github.com/gonum/gonum is possible to create a module for.
Is there any docs on how to achieve that?
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.