Like runhaskell for Go?
Yaegi – Yet Another Go Interpreter
61–70 of 77 posts
Re: Yaegi – Yet Another Go Interpreter
#62Earlier quoted context omitted.
This tends to be more important in dynamic languages where "the outputs" are often hilariously far from what is reasonable to expect. At least that's where I find I use a REPL in Python--load in some poorly-documented 3rd party library to see what the return type of a function is (for some given inputs) and what properties are available on that object (since the "type" isn't much good given the aforementioned poor st…
This tends to be more important in dynamic languages where "the outputs" are often hilariously far from what is reasonable to expect. Most of my experience with dynamic language programming is far from what you describe above. About the only place where I've encountered the like is with Javascript. https://archive.org/details/wat_destroyallsoftware I once experienced "magic" jumps in the debugger in Smalltalk, but th…
This experience is commonplace in Python. Can’t speak so much for other languages.
Re: Yaegi – Yet Another Go Interpreter
#63Bench-marking a fat native call, rather than a purely-interpreted function, is a bit bait-and-switch.
They do explain it very clearly though, and give a reason why that is what they are interested in for business purposes. Benchmark and optimise for what you're running, right? Better than a Mandelbrot?
They explain it, but it's still deceptive.
I would have expected a honest benchmark result. Which will be much worse than 6%.
Which is totally fine! an interpreter will of course be much slower. But this seems like the wrong kind of marketing by omission to me.
Re: Yaegi – Yet Another Go Interpreter
#64Earlier quoted context omitted.
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)
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.
Seems like a wasm interpreter with WASI might be a better approach.
Re: Yaegi – Yet Another Go Interpreter
#65Earlier quoted context omitted.
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.
Seems like a wasm interpreter with WASI might be a better approach.
I've also given that some thought as well. Actually, all of the above could be combined.
Re: Yaegi – Yet Another Go Interpreter
#66Earlier quoted context omitted.
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)
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.
No IO? As in at all?
xor eax, eax here we come.
Re: Yaegi – Yet Another Go Interpreter
#67Earlier quoted context omitted.
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.
No IO? As in at all? xor eax, eax here we come.
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.
Re: Yaegi – Yet Another Go Interpreter
#68Earlier quoted context omitted.
We are talking Go here, which has a fast compiler. The IDE integration isn't always as good as Java, though.
I find GoLand to be quite good.
Seconded, GoLand isn't just quite good, it is phenomenal. If you aren't running it, you need to have a compelling reason.
Re: Yaegi – Yet Another Go Interpreter
#69Earlier quoted context omitted.
No IO? As in at all? xor eax, eax here we come.
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.
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)
Re: Yaegi – Yet Another Go Interpreter
#70Now, you can play with it in the Go Playground https://play.golang.org/p/P--lUj4Vbax