Follow

Building on top of and tired of the ?

Give this DSL/Protobuff approach a look and see if it resonates with you

github.com/cruise-automation/i

I'll be checking this out in the coming weeks and probably have a writeup about my experience with it.

its a golang app that interprets Starlark, a python DSL used in Bezel and other google suites. Has hooks for tests and integration suites. Looks really nice and might promote a paradigm shift

@chuck It's interesting how the outside world keeps inventing the same stuff Google uses internally. BCL/GCL looks so much like Python I was sure it WAS Python the first time I saw it. HCL (Hashicorp's equivalent) and Terraform also look similar. We really need a standard declarative language that can spit out properly typechecked protobufs, Thrift, and JSON from a properly typechecked schema and input file.

@chuck Facebook uses (or at least used in 2015) Python to generate Thrift that then gets serialized as JSON in Configerator, but this of course results in people writing nondeterministic and/or non-referentially-transparent configs. A DSL that's not Turing complete would be ideal, even if it allows plugins in a Turing complete language. At least the plugins can be reviewed to make sure they don't introduce nondeterminism or Turing completeness.

@freakazoid that was goign to be my follow up toot (to the deleted draft) - is that it was a huge deal with TF went touring complete which was antithetical to their original objective.

are we sure we still agree that we want non-touring languages as our deterministic DSL?

@chuck I haven't seen a case where Turing completeness was necessary in the DSL itself. I think what you want to do is restrict Turing completeness to a plugin system.

@chuck It's possible Turing completeness doesn't matter as long as you have type checking. I guess it mainly depends on what other kinds of processing you might want to do on your configs besides generating serialized blobs to send to APIs.

@freakazoid yeah, i do agree that having a strongly typed system would be the bedrock of anything good here.

we're not exactly processing a ton of dynamic unstructured data in this fashion... 🤔

a hostname is pretty much always going to be a string.

and a port will pretty much always be an int.

@chuck Even better, a hostname is always a *hostname*. The typesystem can prevent you from inadvertently dropping it into another field by mistake.

For IPs, you could even have different types for different interfaces on each host, and the type could transparently serialize to the right format, be it IPv4, IPv6, or little-endian hex. No more inadvertently dropping in the IPMI address when you meant to use a serving address.

@chuck It was kinda funny to go from Facebook, where I concluded that such a thing was needed, to Google, which already had such a thing, which Facebook was clearly cargo-culting to make Configerator without understanding the importance of a declarative language.

Of course, Google ALSO has Prodplan (which I worked on) and another language that generates Borg protos from Python because BCL is widely hated.

Sign in to participate in the conversation
LinuxLab

A quiet, safe space. A great place to maintain a minimal social network presence.