I've had great success with the Go Starlark interpreter. Very easy to get started with. I map some of my internal structs to its dictionary type and let CLI callers filter my collections by providing predicates as Starlark expressions.

The mapping to and from Go types is a bit obtuse and could probably be smoothed over by reflection or an intermediate representation like JSON in many cases. It's not just data though: you can also send functions in both directions.

Embedding an interpreter for filtering vs. trying to compile all possible filtering needs into the binary greatly improved my program's power and shrunk the volume of application code. I recommend it.

Don't be alarmed by the Bazel connection: it's much easier to use and understand (and better documented) than Bazel itself. Although I am a lot better at Bazel now for having taken the time to understand Starlark.

All that said: if you find yourself needing to support logic and behavior in your configuration language, you may not actually have a good enough abstraction to justify a config-driven system. Take a hard look at whether it might be cleaner to write plain old code, or APIs for other people's code. A significant number of internal platforms at my company are unnecessarily obtuse because they try to put everything in boxes like this vs. being legitimately composable/programmable through ordinary software engineering tools and processes.

Bazel is convenient but also a full-time pain in my ass.

As someone already put it, 'Bazel is the worst system except all the others'. It has some warts (Python integration, non-hermetic-by-default rules, starlark structure javaesque complexity ...), but I still haven't far a good replacement for my use: a monorepo build system that has to touch a ton of different languages and can be run in CI without having to prebuild tons of fragile builder images.

It absolutely is, especially if you do C++ with it. So many bugs and missing features in the native rules and skylark api, it's not even close to a 1.0

Bazel is the thing that I've missed after leaving Google, (lol "bazel menu"). Back then I was using it on the surface, there were no .bzl files, but internal python rules. I actually hated it when I started, because i was like - WTF is this shit, then I've learned.

My best example would be a CI system, given a CL (changelist) it can tell you exactly what targets need to get built. In our current CI - we have put extreme whitelsits - e.g. if you have touched this folder with C++ files, these are the .sln files to build. But can't move to bazel yet (mostly Windows shop). I actively use it for my home projects (linux + windows), but that's about it.

Thanks, I tend to forget it's actually Starlark, I'll amend.

I guess my point is it's so similar to Python that in most cases I don't even notice.

When you say "not a strict subset of Python", is that primarily the stdlib changes? Are there any syntactic differences that mean valid Starlark is not valid Python?

There aren't syntactic differences, syntactically starlark is a strict subset. But there are some semantic differences/weirdnessess.

`load` does magic, so that `load('//path', 'name')` puts `name` into the file scope, which is possible in pure python but ewww.

Containers are immutable, so they can go in default values, which is good since a lot of bzl and BUILD relies on default arguments for brevity.

Yep yep, makes sense. I helped migrate a Python monorepo to Bazel, which involved an unfortunate amount of Starlark :-)

The mental lines between Starlark and Python are fully blurred at this point, but I've seen the "Starlark isn't Python" a few times this past week already.

Thanks for the elaboration :)

(ask me how I know they're source compatible: https://github.com/bazelbuild/bazel-skylib/pull/91)