[mcpherrinm]

There are some circumstances where an interpreter is useful: For example, it should be possible to make better golang repls with an interpreter than with a binary.

In a "scripting" scenario, you can load some golang code at runtime without needing to bring the full golang compiler toolchain along, which keeps the nice "single binary" deploys of golang. It may be possible to sandbox scripts as well (though I haven't looked into how that could work with this implementation), which could reduce the risk of running scripts (less likely to shoot yourself in the foot. Probably not a security boundary -just look at how much work goes into safe JS in browsers to have that).

[mhh__]

Sandboxing is possible but only if it brings it's own standard library (I think... I'm not familiar with how go implements io at it's roots)

[stcredzero]

I'm working on an approach for Golang sandboxing which works through whitelisting imports, and munging all references, casting operations, and function calls, which lets one whitelist those as well. I would disallow all io and network access.

[the_duke]

Seems like a wasm interpreter with WASI might be a better approach.

[stcredzero]

I've also given that some thought as well. Actually, all of the above could be combined.

[mhh__]

No IO? As in at all?

xor eax, eax here we come.

[stcredzero]

I would be providing an API and handling IO for the client. I'm not disallowing all IO and network access. I'm restricting it to going through my API.

[mhh__]

Could you not just hijack the system calls/c runtime? Then you can still do "safe" I/O without a specific API (Or are you rewriting the stdlib on top of the API? I've never actually used go so I don't really know anything about how it does or doesn't work usually)