Benefits

• It's an answer to the L3+ planning and templating needs.
• Starlark's python-like syntax is easy for almost any developer to adopt.
• It's easy to embed in a golang program and ship. So we can easily make it part of our core tools.

Risks

• It's implemented in golang, and easy to host there... But if we ever move major amounts of tooling out of golang... There are not a lot of other starlark interpreters out there.
• Basically no tooling around it.
  • Syntax highlighting.... Well, Python might work.
  • Type checkers? Lolno. (Though whether one wants that in a templating system like this is highly debatable.)
  • Autoformatter? Nope. (? Check, actually.)
    • Ahha! https://github.com/bazelbuild/buildtools/tree/master/buildifier can do it, apparently.
      • Unfortunate that it's bazel-branded, but if it works, it works.
      • Is also just more go code, so we can build it into our tools and customize as necessary, probably.
  • Some things do exist:
    • A vscode extension: https://marketplace.visualstudio.com/items?itemName=phgn.vscode-starlark

Other usages to inspect

• Qri works with a lot of starlark:
  • docs:
    • https://qri.io/docs/transforms/runtime
    • https://qri.io/docs/transforms/starlib
• Drone apparently supports it:
  • docs:
    • https://docs.drone.io/pipeline/scripting/starlark/

We've started playing with it

See https://github.com/ipld/go-datalark !

(TODO: get QRI interested in this too — there should be plenty of people able to collaborate on this part!)