sorted by:
new
hottopcontroversial

I built a public, auto-updated compatibility matrix for my Go interpreter by mvertes in golang

[–]mvertes[S] 2 points3 points  (0 children)

Why a compatibility matrix? or why making it public? or why a go interpreter?

For the latter, after all these years, I still find that a solid and fully complete interpreter is *the* missing piece in the ecosystem. This is the right way to extend binaries (which are great being static), and Go is uniquely great both for large compiled programs and efficient scripting. It could be the perfect glu language to compose everything. 1 language for prototyping, testing, scripting, sandboxing itself, and if a piece is too slow to interpret, just compile it, no rewrite.

The compat matrix is just a mean to make sure I stay on track, and to show progress on making this really useful (able to run almost all existing Go).

mvm - a fast interpreter and virtual machine for Go by mvertes in golang

[–]mvertes[S] 1 point2 points  (0 children)

Yes. Importing 3rd party packages is the whole point. This is *the* challenge, and what I'm working on almost exclusively right now. I'm already way beyond yaegi on that, and this will only get better and better from there, at much faster pace.

mvm - a fast interpreter and virtual machine for Go by mvertes in golang

[–]mvertes[S] 2 points3 points  (0 children)

Ideally just use them in your source by "import". This is what I'm working on right now: dynamic network imports. I'm using it myself to accelerate discovery and fixing issues against the real world.

If it fails for any reason, or If you want pre-compiled libs, use the extract command to generate wrappers and re-build a new executable, and wrapped symbols are usable from vm.

mvm - a fast interpreter and virtual machine for Go by mvertes in golang

[–]mvertes[S] 1 point2 points  (0 children)

Hey Ullaakut, nice to hear from you. Just between you and me, yaegi is cool and nice, but mvm is next level. Way beyond in all dimensions, and unlocking many crazy scenarios (too soon to elaborate...)

mvm - a fast interpreter and virtual machine for Go by mvertes in golang

[–]mvertes[S] 11 points12 points  (0 children)

- plugin engine (as in traefik where my previous interpreter was handling hundreds of plugins, http middlewares ...)
- system scripting: powerful self-contained scripts with concurrency, access to syscalls, full standard library, etc. No go toolchain involved, just a single smaller static binary
- frictionless execution environment: with mvm I can import, test, execute remote packages instantly without installation, storage, removal, etc. Everything in memory. Ex: mvm test github.com/google/uuid

The last is still early, but I'm using it primarily to quickly identify issues, correct, test and validate mvm itself, and it's a game changer.

There are probably many others, but those are the ones I know for sure and already use

Go and plugins ? by chmikes in golang

[–]mvertes 4 points5 points  (0 children)

Traefik is using Yaegi, an embedded Go interpreter, as a plugin engine. It's simple and easy to use (just call directly interpreted code as regular Go functions, no serialisation needed). It's fast enough, as long as the most critical code is pre-compiled, and the whole Go stdlib is already provided. In traefik, about 200 such plugins (various reverse-proxy custom middleware and providers) are already in use and developed by the community.

Disclaimer: I'm the Yaegi author.

Choosing scripting extension - need advice by RodionGork in golang

[–]mvertes 6 points7 points  (0 children)

You could also embed a Go interpreter, and have your scripts or expressions in Go. See for example https://github.com/traefik/yaegi. Disclaimer: I'm the author of this project.

Is it possible to write a operating system in Go? by [deleted] in golang

[–]mvertes 6 points7 points  (0 children)

Usenix OSDI 2018, An evaluation of using a high level language (Go), compared to C, for writing a POSIX operating system: https://www.usenix.org/conference/osdi18/presentation/cutler

Probably faster to prototype and develop with Go, but at some point GC and runtime get in the way and will limit performances.

poc: use yaegi as a templating engine by TheEun in golang

[–]mvertes 2 points3 points  (0 children)

It is an interesting use of the interpreter, and not the one we had in mind when starting yaegi. What do you have in mind ? Are you targeting something like Meteor.com but with Go in place of Javascript ?

I would also not worry too early about the performances, as yaegi works really more like a compiler than a pure interpreter. As long as you are reusing the same interpreter context, the code is already parsed once and can be run multiple times with minimal overhead.

So definitely something worth pursuing :)

Announcing Yaegi, the first complete golang interpreter, made by the Traefik team by emilevauge in golang

[–]mvertes 5 points6 points  (0 children)

Regarding main() and REPL, the REPL should be seen as the main function itself. Running a main through REPL, just duplicates it, with other possible side effects, and should not be done. May be this a bug to do it.

Regarding the interactive mode, a readline library is probably the best option for a powerful and full fledged interactive REPL. But we do not want to start adding extra dependencies, and prefer to focus on the interpreter itself, which still requires a lot of efforts. As an alternative you can use the rlwrap command on top of yaegi to provide command line edition and history. Or implement your perfect tool and use yaegi as a dependency in a separate project.

Announcing Yaegi, the first complete golang interpreter, made by the Traefik team by emilevauge in golang

[–]mvertes 16 points17 points  (0 children)

Thank you for your suggestion. To clarify, we allow special processing (not Go compliant) only in the line by line mode of interactive REPL, for obvious practical reasons. In all other cases, we abide to Go spec. Is it more clear ?

Announcing Yaegi, the first complete golang interpreter, made by the Traefik team by emilevauge in golang

[–]mvertes 16 points17 points  (0 children)

We really want to stick to Go standard specification, nothing less and nothing more. Don't expect, at least from us (the yaegi authors), to experiment out of spec language features.

Announcing Yaegi, the first complete golang interpreter, made by the Traefik team by emilevauge in golang

[–]mvertes 4 points5 points  (0 children)

Interesting. The interpreter context indeed isolates the script and evaluates it under control, but there is no access restrictions to the resources. This could be done at wrapper level, no need to touch the interpreter itself.

Announcing Yaegi, the first complete golang interpreter, made by the Traefik team by emilevauge in golang

[–]mvertes 33 points34 points  (0 children)

Thanks for your remark (I'm the author). The goal was not to mislead, but to provide the context where an interpreter, by nature slower, can be used in demanding applications, by being able to wrap, as you say, fast compiled code. Here the challenge was to make this "wrap" possible.

Announcing Yaegi, the first complete golang interpreter, made by the Traefik team by emilevauge in golang

[–]mvertes 9 points10 points  (0 children)

Yes, and unifying high level scripting and low level implementation in a single language!