3 ms·

There are a couple different Lua implementations in Go. Has anyone researched the difference between them? https://github.com/yuin/gopher-lua https://github.co

There are a couple different Lua implementations in Go. Has anyone researched the difference between them? https://github.com/yuin/gopher-lua https://github.com/yuin/gopher-lua https://github.com/Shopify/go-lua https://github.com/Shopify/go-lua https://github.com/milochristiansen/lua https://github.com/milochristiansen/lua https://github.com/afitz/golua https://github.com/afitz/golua

wahern 9y ago
Milo Christiansen's seems to be the only Lua 5.3 implementation. Note that Lua's versioning scheme is not like most other languages. Lua 5.1, 5.2, and 5.3 are not the same language. Though most code will still work across those versions, the Lua developers are more aggressive at adopting new features and killing old ones, even for core functionality. 5.2 dropped function environments in favor of lexical _ENV, which was a huge change for people implementing sandboxing, reflection, module frameworks, etc. 5.3 added an integer type whereas previously all numbers were floating point, and because Lua is dynamically typed you can't move an existing body of Lua code to 5.3 without some careful attention. Similarly, the APIs also have incompatible changes that while mostly simpe to deal with require porting attention. This more aggressive style of stewardship is what has made Lua an amazingly elegant and powerful language, but reduces it's attractiveness for large, monolithic, long-lived frameworks unless they're prepared to periodically upgrade languages and migrate their user base. Since Lua is more typically used for extension and embedding (i.e. not monolithic, pure-Lua projects), this is less of an issue. I was explaining to a colleague the other day that the reason you don't hear so much about Lua is because choosing Lua isn't a decision that dominates a project. A project that heavily uses Perl is a Perl project; one that uses Python is a project. For the most part, you don't build Lua applications; you build C, C++, or w'ever applications that use Lua, even when 90% of the code is in Lua. This is a reflection of the carefully crafted API and language semantics. But IMO it's the biggest reason why Lua hasn't yet had a break-out moment, despite Lua 5.1, 5.2, and 5.3 being (IMNSHO) far superior languages to JavaScript, Perl, Python, Ruby, or other similar dynamic languages. Lua is a better language because it aggressively improves itself. But that evolution is too rapid to support many large, marquee projects.
- fao_ 9y ago
  In my experience the difference between 5.2 and 5.3 was more towards "negligible" than you're making out. While the functional difference may have been major, most programs in my experience operate exactly as you would expect them. For the majority of programs I doubt that they were even felt, aside from a few minor changes like "unpack" -> "table.unpack"
  - TheCycoONE 9y ago
    The biggest issue I hit when adding Lua 5.3 support to CorsiTH was that floating point numbers now crash when sent to a C function that expects a lua_Integer whereas before they would be silently truncated. Since we still support 5.1 as well I ended up scattering a lot of math.floor to compensate. That said it was trivial compared to the _ENV change for 5.2
  - wahern 9y ago
    That's been my experience, too. And the consensus on the lua-l list seems to be that the migration to mixed number types went relatively smoothly for most people despite the anxiety. But people were still anxious, even gung-ho Lua users. Whether or not justified, people and companies contemplating large projects are especially averse to that sort of environment. My open-source project experiences notwithstanding, before I left my day job a few months ago we still hadn't migrated our 10+ year-old project to 5.2, let alone 5.3, even though LuaJIT wasn't involved, and even though lua_callk and lua_pcallk would have significantly simplified the libevent async I/O integration. In a corporate environment planned obsolescence is a hard to sell, even when it's objectively the better choice.
- fosk 9y ago
  > Since Lua is more typically used for extension and embedding The LuaJIT (http://luajit.org http://luajit.org) is another reason why Lua is very popular (although it only officially supports Lua 5.1). It’s a very fast implementation of the Lua VM. OpenResty (https://openresty.org/ https://openresty.org/) is a very popular framework that allows Lua scripting on top of NGINX and LuaJIT, and it’s the same stack that Cloudflare uses. Basically over 5% of the world internet traffic goes through Lua, but only a few people know it. This is the same stack that Kong (https://github.com/Mashape/kong https://github.com/Mashape/kong) also uses, probably the most popular OpenResty-based application. Lua on top of LuaJIT can be extremely fast especially if you leverage FFI. Lua is an extremely simple language which can be pretty much embedded anywhere, and the LuaJIT just does a great job at making it extremely embeddable and fast. Disclaimer: I am a core committed at Kong.

wahern 9y ago

Milo Christiansen's seems to be the only Lua 5.3 implementation. Note that Lua's versioning scheme is not like most other languages. Lua 5.1, 5.2, and 5.3 are not the same language. Though most code will still work across those versions, the Lua developers are more aggressive at adopting new features and killing old ones, even for core functionality. 5.2 dropped function environments in favor of lexical _ENV, which was a huge change for people implementing sandboxing, reflection, module frameworks, etc. 5.3 added an integer type whereas previously all numbers were floating point, and because Lua is dynamically typed you can't move an existing body of Lua code to 5.3 without some careful attention. Similarly, the APIs also have incompatible changes that while mostly simpe to deal with require porting attention. This more aggressive style of stewardship is what has made Lua an amazingly elegant and powerful language, but reduces it's attractiveness for large, monolithic, long-lived frameworks unless they're prepared to periodically upgrade languages and migrate their user base. Since Lua is more typically used for extension and embedding (i.e. not monolithic, pure-Lua projects), this is less of an issue. I was explaining to a colleague the other day that the reason you don't hear so much about Lua is because choosing Lua isn't a decision that dominates a project. A project that heavily uses Perl is a Perl project; one that uses Python is a project. For the most part, you don't build Lua applications; you build C, C++, or w'ever applications that use Lua, even when 90% of the code is in Lua. This is a reflection of the carefully crafted API and language semantics. But IMO it's the biggest reason why Lua hasn't yet had a break-out moment, despite Lua 5.1, 5.2, and 5.3 being (IMNSHO) far superior languages to JavaScript, Perl, Python, Ruby, or other similar dynamic languages. Lua is a better language because it aggressively improves itself. But that evolution is too rapid to support many large, marquee projects.

fao_ 9y ago
In my experience the difference between 5.2 and 5.3 was more towards "negligible" than you're making out. While the functional difference may have been major, most programs in my experience operate exactly as you would expect them. For the majority of programs I doubt that they were even felt, aside from a few minor changes like "unpack" -> "table.unpack"
- TheCycoONE 9y ago
  The biggest issue I hit when adding Lua 5.3 support to CorsiTH was that floating point numbers now crash when sent to a C function that expects a lua_Integer whereas before they would be silently truncated. Since we still support 5.1 as well I ended up scattering a lot of math.floor to compensate. That said it was trivial compared to the _ENV change for 5.2
- wahern 9y ago
  That's been my experience, too. And the consensus on the lua-l list seems to be that the migration to mixed number types went relatively smoothly for most people despite the anxiety. But people were still anxious, even gung-ho Lua users. Whether or not justified, people and companies contemplating large projects are especially averse to that sort of environment. My open-source project experiences notwithstanding, before I left my day job a few months ago we still hadn't migrated our 10+ year-old project to 5.2, let alone 5.3, even though LuaJIT wasn't involved, and even though lua_callk and lua_pcallk would have significantly simplified the libevent async I/O integration. In a corporate environment planned obsolescence is a hard to sell, even when it's objectively the better choice.
fosk 9y ago
> Since Lua is more typically used for extension and embedding The LuaJIT (http://luajit.org http://luajit.org) is another reason why Lua is very popular (although it only officially supports Lua 5.1). It’s a very fast implementation of the Lua VM. OpenResty (https://openresty.org/ https://openresty.org/) is a very popular framework that allows Lua scripting on top of NGINX and LuaJIT, and it’s the same stack that Cloudflare uses. Basically over 5% of the world internet traffic goes through Lua, but only a few people know it. This is the same stack that Kong (https://github.com/Mashape/kong https://github.com/Mashape/kong) also uses, probably the most popular OpenResty-based application. Lua on top of LuaJIT can be extremely fast especially if you leverage FFI. Lua is an extremely simple language which can be pretty much embedded anywhere, and the LuaJIT just does a great job at making it extremely embeddable and fast. Disclaimer: I am a core committed at Kong.