GopherLua: VM and Compiler for Lua in Go | Hacker News Reader

GopherLua: VM and Compiler for Lua in Go

github.com

147 pointstombenner16 comments

On a similar note, there's a clojure-like (syntax) embeddable VM called glisp: https://github.com/zhemao/glisp. I've been tinkering with it to add dynamic plugins to some golang programs.

I'd be interested if someone were to benchmark it against GopherLua.

Interesting that it implements Lua 5.1 rather than any of the newer versions. Is it because LuaJIT implements 5.1, thereby making that the de facto canonical language version?

Lua 5.1 is the most widely used. LuaJIT is a big factor. But changing existing code to use the 5.2 API is not worth the few changes 5.2 offered. The 5.1 API has the most libraries. Many existing code bases try to stay compatible with 5.1.

This situation may change as 5.3 adds many nice changes.

From a quick glance at the source, it looks like this may be a port of the existing Lua VM for C into Go.

For example, it appears to use the same opcodes and the main VM loop looks very similar:

http://www.lua.org/source/5.1/lvm.c.html

https://github.com/yuin/gopher-lua/blob/master/vm.go

It's interesting because the Go source appears to be annotating certain patterns with comments where the C version uses a macro. Compare the C version:

        case OP_LOADK: {
          setobj2s(L, ra, KBx(i));

With the Go version:

        case OP_LOADK:
                Bx = int(inst & 0x3ffff) //GETBX
                reg.Set(RA, cf.Fn.Proto.Constants[Bx])

And what a useless comment GETBX is.

This in itself isn't a bad thing. When I'm porting code, I try to start with a proven code-base and port from there, while iterating the code to make it more idiomatic (e.g. "case OP_LOADK" is not idiomatic Go).

The problem is, if the author has based their code on this library, they seem not to have credited it (At least, I couldn't find it on my cursory look at the file headers).

Well it certainly beats javascript on the fibonacci benchmark, clearly this is the language of the future.

Stupidest benchmark ever. Tests nothing but procedure call speed.

Still though, Lua kicks JS' ass ..

Procedure call speed does matter.

Is it any way better/faster than luajit or vanilla lua? I can't understand why people are so excited about it.

The excitement is because Lua is a very nice little language with the explicit goal of being embedded into programs, so when a pure-go port of the language appears that is not just bindings to the C version it is warmly welcomed.

And no, it shouldn't be any faster than luajit (what can really :)

Its just an extension language for go programs, The advantage is that is uses the go garbage collector, and can interop with Go code nicely.

Been waiting for someone to make languages in Go to see the results

Reminds me of this: https://twitter.com/Steve_Yegge/status/372156022913122304

That's a brilliant comment!

I've noticed that Go seems to be fairly popular for emulators / simple VMs as well. I'm currently working on a SID emulator in Go, and I'm finding it quite fun! (unfortunately, it means that I then need to write a proof of concept synth-like API to the SID, then a proof of concept sequencer to control the synth...)

Damn rabbit holes.

Reply on news.ycombinator.com