jk VS isopod

People have tried: https://github.com/jkcfg/jk

But yeah I agree. The thing is, if all you need is robust determinism why do you need a full functional language with currying and other complex concepts?

Google had the same problem for Bazel, and their solution (Starlark) is way easier to understand.

If I were writing a build system today (and I did just write one actually to test out some ideas) I would use Typescript for the language with something like jk to provide hermeticity. Typescript has many advantages, especially over Python, but mainly:

It's possible to sandbox most languages, and with some work you can probably make them deterministic too.

Here's an example: https://github.com/jkcfg/jk

That beats having to learn an entirely new language.

Maybe Javascript? A lot of web tools support Javascript config files. There's this nice-looking effort to provide a hermetic execution environment for them: https://github.com/jkcfg/jk and if you use Typescript you get an extremely good static type system too. Plus the language is already very well known with loads of tool support and documentation.

Definitely what I would use today.

If you think "but I need conditionals and file inclusion and ..." then maybe consider just allowing a full programming language instead. Someone pointed me to jk which looks like it is heading in the right direction, except that it outputs YAML by default for some insane reason.

You may be interested in jk. If you don't want to use a special purpose configuration language (jsonnet, cue, dhall, etc), this is a nice alternative that uses js in a hermetic runtime (but see their open issues for progress on that). They seem to also be adding native typescript support so you could even have type checking built-in.

Tried it[0], worked reasonably well. Be prepared for strong opposition from traditional “devops” folks “who don’t mind yaml” and will drag everyone down.

[0] - https://github.com/cruise-automation/isopod

I like Cue and Jsonnet and Starlark and so on. But all of these have very low mindshare (though Starlark has the most momentum thanks to Bazel), and who knows if they will be dead by next year.

Being an early adopter is difficult both in terms of the immaturity of the tooling — Cue, for example, only has a Go implementation at the moment — and in terms of the risk of betting on an evolutionary dead end, which can cause a lot of unnecessary churn when you want to standardize on something across an entire organization.

As a concrete example, I'd love to replace Kubernetes's use of YAML with something like the above. But the tooling is immature, and almost nobody is using any of it. For example, there's Isopod [1], which is a nice-looking tool to use Starlark with Kubernetes. But it might go the same way as Ksonnet.

[1] https://github.com/cruise-automation/isopod