Lua - Part 11

Luakit is a highly configurable browser framework based on the WebKit web content engine and the GTK+ toolkit. It is very fast, extensible with Lua, and licensed under the GNU GPLv3 license. It is primarily targeted at power users, developers and anyone who wants to have fine-grained control over their web browser’s behaviour and interface.

lsqlite3 is a thin wrapper around the public domain SQLite3 database engine. The lsqlite3 module supports the creation and manipulation of SQLite3 databases. After a require('lsqlite3') the exported functions are called with prefix sqlite3. However, most sqlite3 functions are called via an object-oriented interface to either database or SQL statement objects.

The issue from a hosting provider is the platform has to be 100% sandboxes; cpu, heap, network and file system access. Lua is the only runtime that provides this level of control. SQLite can do massive multi tenancy and acceptable performance if used correctly.

We need a Lua 5.3 engine, and the others were not, nor where they interested in updating

The VM is designed differently (I'm encouraging Brian to write a blog post about this), but in a nutshell it is designed for better error handling and for adding a debugger

We wanted an implementation that was closer to the Lua spec than some of the others. We haven't totally nailed that, but we're getting closer by the day

We also wanted clean and idiomatic Go APIs

Before starting on this path, we had been using other Go Lua implementations for quite a while. We just finally arrived at the point where it became evident that our needs were not going to be met.

Eventually we will add more documentation to the README. We honestly didn't think people would discover (let alone use) this project the day we open-sourced it. So it's been a pleasant surprise, but one that caught us off guard.

Comment from the HN thread:

I'll admit I don't use or know Go, but I have been in the Tarantool docs lately. It is a JIT compiled "drop in replacement for Lua 5.1 or JIT" and has fibers and channels inspired from Go.

The above is shorter and also significantly more efficient because you're not creating the intermediate table object. Even in Go, given Lua's coroutine and tailcall semantics (assuming they were implemented) the Go compiler would likely be forced to always heap allocate the argument list table. There's a reason PUC Lua is blazingly fast, and its partly the same reason why LuaJIT is so fast--the Lua stack protocol is a thin abstraction that easily admits a simple, efficient implementation yet still managing to provide an effective interface boundary that doesn't leak (beyond the fact of the protocol itself).