jacobin VS otto

Thanks for your note. The package notes on Jacobin say that we strongly discourage folks from running it in its present form. There are enough features still to be implemented, that for anything but trivial classes, you won't have a good experience. TBH, we're about a year out (we think) from having a version we can solicit users to test.

Nonetheless, if you'd be kind enough to post the above error and the class you used into the GitHub Issues tracker [0], we'll definitely include it in our test suite and make sure whatever the problem is, it'll be corrected.

[0] https://github.com/platypusguy/jacobin/issues

Then might want to look at Jacobin, which is a project developing a JVM (Java virtual machine) in Go. It includes a detailed roadmap of the source code, which lays out the architecture of the code and makes it easy to jump in. The code itself is well commented and there are numerous tests, which provide additional insights.

robertkrimen/otto

Ummm, excuse me, but where the f&$k has this been hiding? I’ve been looking for ways to extend my go applications with scripting support. I started with Lua (worked ) then Python (worked but hacky) then javascript using otto [1]. However it lacks ES6 support so having pretty OOP js code is a non-starter. I would love to have Java as a runtime that can be executed from goroutines.

[1] https://github.com/robertkrimen/otto

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.

Otto https://github.com/robertkrimen/otto Seems interesting. It lets me call Go functions from inside JS as well as return results. The fncs pattern reminds me a bit of how the template engine works.

> why host other languages

Here's an example:

I recently finished building https://subzo.com.au which allows customizing and ordering 3D models. The way the model's cost, volume and other attributes are calculated needs to be done both on the frontend (for speed) and on the backend (to validate). Backend is in Go and we can't practically run Go in the browser. So instead, I wrote the calculation snippets in JavaScript (which runs natively in the browser) and ran them on the backend on a JavaScript VM library written in Go [1].

[1]: https://github.com/robertkrimen/otto

Googling suggests https://github.com/robertkrimen/otto which allows scripting in javascript for golang projects. This would be definitely enough, but in some way it may be a bit overkill - and scripts supporter shall need some knowledge of javascript which is not always straightforward :)

It doesn't make sense to ask the user (aka me) to change the code every time I want to modify any web apps right? So I decided to split the webapps into two parts. WebApps are those only require basic permissions and do not interact with the host OS. They will be run inside a sandbox created using ECMA5 VM called Otto. The other type is called Subservice, in which it will need extra permission to interact with the OS and require higher level of access to the backend file system.