Today I Came Across #1: Starlark configuration language
Starlark (formerly known as Skylark) is a language intended for use as a configuration language. It was designed for…
Have you worked with Makefiles? For a small project, that does work like a charm. But if you’re lucky (or maybe unlucky) enough to work on a project long enough, you’ll start facing the issues once the project becomes sophisticated enough, and the number of Makefiles and imports of those into other Makefiles starts giving you nightmares.
If you have multiple repositories, or (sub)projects using the same/similar makefiles, the only sane option is to start writing scripts that generate Makefile, or you execute the script/program from Makefiles. And most people Go (pun intended) with Python due to the ease it provides.
At first glance, Starlark (previously named Skylark as) is a subset of python to be used as a configuration language.
Design Principles (mentioned in )
- Deterministic evaluation
A no-brainer, not sure why they even said this.
- Hermetic execution
Execution can’t access external resources like system, network, clock.
- Parallel evaluation
I guess without this; there is no point to move from Makefile realm ( -j for the win ).
- Simplicity, Python-like and Tooling-focused
It’s a configuration language; it should be quick and easy to read.
Only lists and dictionaries are mutable; all other variables are immutable. Also, the lists and dictionaries are immutable (and will cause runtime error) if another thread tries to update them. (Example)
In a way, this enforces assignments at the top of the file.
- No recursive functions
Probably to make things simpler and avoid infinite loops. It also doesn’t support unbounded loops.
- And a lot of restrictions
No iterations on a string, no “is” operator or chained operators,
In a nutshell, it is a strict subset of Python, with significant features removed to keep it as simple as possible and to avoid pitfalls (one of the mentioned goals in the design section of language).
You can go through spec and details here.
It’s used mostly to evaluate and execute .bzl files as of now, mainly at Google (Obviously!!! :)).
Moral of the story:
When you don’t trust your devs, put linters on the language. But if the linters don’t suffice, create a “new” language. Because a slice of an apple is not an apple.
Disclaimer: As part of TICA series, I’m just trying to understand things I came to know about recently. Please feel free to correct me because it’s very likely that the information or understanding mentioned here is incorrect.
One can always write about things one has worked on, but what’s fun in it?