Will go-jsonnet supersede the c++ version?

[ashi009]

Hi jsonnet team,

As golang is now the preferred language for ops, will go-jsonnet become the de facto implementation for jsonnet?

IMHO, the go version is more likely to be adopted by the community as a library. Also from code readability perspective, golang version is more likely to get merge-able PRs.

[sparkprime]

It is preferable to have only one implementation being maintained. The current version should be good enough to use instead of the C++ version for the vast majority of people. There are some remaining questions about performance, it is possible these are innate to Go, but maybe also we can streamline the Go implementation to narrow the gap. Also, we could invest in more high level optimizations (like Jsonnet code transformations) that would close the gap in different areas.

Another question is how to convert it to Javascript. I experimented with gopherjs which seemed to work ok but I didn't try to stress it. I'm not sure it can handle deeply recursive Jsonnet programs. The bar is low though, because the existing empscripten Javascript build is not very good either.

I agree that the Go version should be preferable, but it may be a while before we can deprecate the C++ version.

[mqliang]

@sparkprime

May I ask what "Jsonnet code transformations" is ?

[sparkprime]

Things like hoisting locals out of loops / objects if possible. Maybe constant propagation, that kind of thing.

edit: also inlining

[marcelocantos]

Does anyone have numbers for the current performance delta? What would be the preconditions for fully switching development to Go? I would much prefer to contribute to a single implementation than two, and would prefer it to be Go.

Of course, one issue might be Python integration.

[sbarzowski]

Some things we should do before considering go version official off the top of my head. 1) We need a common, unified test suite of e2e tests. Currently it's possible to run Go version on C++ tests, but not the other way around. Ideally it would be just one unified suite (in a separate repo?).

2) Include some benchmarks in this test suite.

3) Make performance a bit better. The performance is varying a lot and my hypotheses about why were proven wrong multiple times by the experiments. For example this program: std.foldl(function(x, y) x + y, std.range(1, 100000), 0) is 4x faster in C++ jsonnet. But to seriously work on performance we need a standard set of benchmarks.

That said, there's some low hanging fruit that can be worked on right away. For example builtin implementations for functions in stdlib.

4) Compatible C bindings - libjsonnet. This lets us keep bindings to other languages. Python bindings will not be a problem, as a matter of fact, Python is used to test the partial implementation of C bindings that we currently have (compat_test/compat_test.py).

5) Some cleanup - making sure the right things are exported etc.

[sbarzowski]

I think the question was answered and we can close this. We are still going in this direction (e.g. recently we reached full compatibility with C api).