Choosing an interpreter for running executors

[qzb]

Klio lifecycle commands need scripting language engine for running executors (builders, deployers, etc). Currently they are using goya, but it was chosen as a temporary solution, without evaluating other options.

Good interpreter should meet the following requirements:

• It has to be small - chosen engine is going to be included in every binary, it shouldn't add 3MB to each one of them.
• It should have good documentation for both itself and a language.
• It should have good standard library, otherwise we need to create it by our own.

Which engines are taken into consideration?

Stats as at 16 Sep 2021.

Package	Language	Stars	Watchers	Forks	Last Commit
otto	JavaScript	6222	189	521	14 Jun 2021
goja	JavaScript	2386	66	201	12 Sep 2021
go-ducktape	JavaScript	778	28	90	26 Mar 2021
gopher-lua	Lua	4289	149	477	29 May 2021
go-lua	Lua	2152	312	156	2 Mar 2021
golua	Lua	555	34	193	7 May 2021
go-python	Python	1303	43	128	14 Apr 2021
gpython	Python	517	21	58	18 Nov 2019
yaegi	Golang	3816	50	183	15 Sep 2021
tengo	Tengo	2422	57	141	5 Sep 2021
starlark-go	Starlark	1367	46	122	1 Sep 2021
anko	Anko Script	1167	47	111	21 May 2020
go-php	PHP	42	811	92	1 Oct 2018

Additional size of commands

Following numbers are based on interpreters integrated with build command, compared with
interpreter-less version.

Package	Compressed	Uncompressed
goja	3.19MB	7.63MB
gopher-lua	1.13MB	2.47MB
otto	1.21MB	2.81MB
tengo	0.36MB	0.86MB

Standard libraries

Relevant features supported by standard libraries:

Package	File System	Exec	HTTP	Regex	JSON	YAML	Print	Date & Time
goja	no	no	no	yes	yes	no	yes*	yes
gopher-lua	yes	no	no	no	no	yes	yes	yes
otto	no	no	no	yes	yes	no	yes	yes
tengo	yes	yes	no**	yes	yes	no	yes	yes

* Provided by an additional library
** Maintainers are open for idea of adding it

Remarks

goja

• Simplest to integrate.
• Too heavy - it adds 3MB to compressed binary.
• Has partial support for ECMA 2015+, but it's poorly documented which features are actually supported.
• JavaScript is a divisive language.

gopher-lua

• Using it wasn't a pleasant experience. For example, using userdata as a table froze command without any errors.
• Awful API.
• IO API is too barebone to be useful.
• Lua has some quirks, it tend to be hard to use for new developers.

otto

• Substantially harder to work with than goja.
• No support for ES2015 or later.
• Errors tend to be a little bit cryptic.
• JavaScript is a divisive language.

tengo

• Uses custom language, but it's quite nice and easy.
• Documentation could be better, but isn't the worst either.
• Has some issues with converting Golang types to Tengo, but they can be circumvented by
  marshalling/unmarshalling.
• Pretty good standard library.
• It's really small, it adds only 0.36MB to compressed binary.

gpython

• There is no documentation how to integrate it into golang app.
• Seems to be no longer actively maintained.
• Passing data into VM is not supported.
• Seems to be no way to extract data from a VM.
• Everybody loves python.

yaegi

• Full-blown Golang interpreter, not suitable for scripting.