ALalexk·Jan 24, 2019
> But say we went with that. Then we'd need to adopt an existing JS engine (most likely written in C++) and then modify it based on our needs.
This is definitely not an easy choice to make and writing a new language interpreter in Go seems a way easier approach initially.
One thing that Go helped me to understand though, is that the language does not matter so much as the tooling around it - debugging, compiling and support around the language are way harder to achieve than writing a language parser.
Thanks for sharing your thoughts on this design choice, I think this discussion is very relevant for a couple of reasons:
There are other Go projects that are taking the same approach to achieve simplicity and not picking the existing language, like OPA [1]. Others, like Helm are picking Lua [2], so there is clearly a problem the Go and infra
Read the rest
structure community is facing and split in the way people are approaching it.
We've faced the similar dilemma with Teleport, as we are designing our extensions system. My original plan was to use Lua, however after discussions with the team we settled on GRPC with Go [3], trading expressiveness/simplicity and freedom of lua/js languages in favor of industrial features Go runtime and GRPC provides out of the box.
For smaller extension plugins we decided not to create a new language, and ended up with interpreted subset of Go [4].
I wonder if there is a place for some subset of javascript or typescript that is fully interpreted by Go, with native extensions for debugging
to be used by the community.
[1] OPA policy agent https://www.openpolicyagent.org/
[2] Helm 3.0 Lua plugins https://github.com/helm/community/blob/master/helm-v3/005-pl...
[3] Teleport Plugin Design Document https://docs.google.com/document/d/1sPXXxx03P8VXWy-YD5w190g7...
[4] Subset of Golang https://github.com/vulcand/predicate