goja VS gopher-lua

We will be using the goja library, a JavaScript VM written in Go, to execute JavaScript code. This setup allows developers to provide custom transformation logic for http payloads and headers.

dop251/goja

Your comment was posted 4 minutes ago. That means you still have enough time to edit your comment to change it so it contains real URLs:

<https://github.com/PuerkitoBio/goquery>

<https://github.com/dop251/goja>

(Please do not reply to this comment—I won't be able to delete it once the previous post is fixed if it contains replies.)

Apparently "not depending on Node or V8" means depending on some random Go JS engine instead.

Goja https://github.com/dop251/goja

Either call a JavaScript interpreter like node with exec.Command and read its stdout, or use a pure Go JavaScript interpreter like goja or otto.

Just to also say this is implemented in pure Go we aren't including V8 or any external dependencies we instead use https://github.com/dop251/goja which is a JS VM written completely in Go.

Adding a JavaScript VM to the Go project turned out to be quite easy and allows easily customizable data transformations. The goja library provides an efficient and straightforward way to execute JavaScript code in Go without using V8/CGO. Another option would have been to use lua scripts via gopher-lua for example. That could be an idea for a future project.

Would be neat to see graph of recent versions with linear scale

I checked, they use switch on opcodes in vm.go. So would expect a recent improvement, but probably only <5%, & I didn't look close enough to see if awk is one of those languages where instruction dispatch matters less (like how APL tends to avoid issues since array ops avoid having dispatch in tight loops, or how Python avoids instruction dispatch overhead when using numpy)

For VMs Go had a problem for large switch statements: it would always use binary search instead of a jump table. This caused gopher-lua & go-lua to both take the route of having an array of functions which they call on to dispatch instead

A couple years ago this was fixed: https://go-review.googlesource.com/c/go/+/357330

I measured a small perf improvement switching gopher-lua to switch: https://github.com/yuin/gopher-lua/pull/479

Not the parent but there are several high quality native (meaning no CGO) Lua implementations for Go and it's a great choice if you want an embedded scripting language:

https://github.com/yuin/gopher-lua

The "game" was just an example, what I'm exactly trying to do is creating a plugin system for my go app using gopher-lua. The thing is the app will be used by end users and I can't ask them to install libraries. ATM, I don't care about libs with external dependencies like openssl, zlib etc. supporting just the pure Lua ones is enough

I'm generally using Visual Studio Code for all my development. Really like it.

I chose https://github.com/yuin/gopher-lua as the Lua engine because it is Golang-based, while the Nginx Lua VM is C, unless I'm mistaken. Using gopher-lua is just easier when I'm working in a Golang project. I only have to work in a single language and dev environment for all the backend work. Makes both development and testing easier.

Moonscript I might have heard of, but I have no experience with it. I did not consider it here, and I would rarely consider any niche scripting language for a solution I want others to use. It just introduces an unnecessary barrier to adoption.

GopherLua [0] is a Lua implementation written in Go, not just a wrapper around the C implementation.

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.

[0] https://github.com/yuin/gopher-lua

[1] https://github.com/Shopify/go-lua

[2] https://github.com/Azure/golua