Your mileage may vary, but Starlark was one of the most complicated languages I've ever read. No types, just layers and layers of indirection, with the goal of making a very complex build rule look "simple". I don't like hiding non-accidental complexity, in particular when the abstraction leaks everywhere. Perhaps it was only due to the Starlark I was exposed to (I worked at Google, probably most of the Starlark code I've read has been written by SREs).
[dead]
This appears to be the same language that started as a custom build rule DSL for bazel (and evolving from lessons learned in blaze's Python extension), the page positions it as a much more general-purpose embedded language.
I'm all for using the right tool for the job, and I'll acknowledge the benefits of hermeticity and parallelism in many contexts. But, I also think that you need to weigh the cost of adding another language to a project. I don't imagine myself using this anywhere outside of a build system, and even then I would first try to take the declarative rules of that build system as far as I can. It's probably better than shell scripts, though, at least most of the time? May depend on your team's prior familiarity with shell and/or love of Python.
There are three implementations (Go, Rust, Java) which could be a good thing if the language doesn't change often. They would have to be kept in sync for any changes, as well as keep from drifting due to changes in the host language's semantics.
I also think that the closeness in syntax with Python can be a disadvantage, especially if users are expecting more recent Python additions like the walrus operator or pattern matching to be available.
I like to design languages, too, so these comments come from a place of love and understanding. I think it would help if there were some more specific justification (or examples) of why this is better than something more established (e.g. Lua or MicroPython) or more distinct (e.g. pure data in configs instead of embedded code). I do like that the language attempts to remain as simple as needed.
Starklark isn't exactly "functional" but by design it is hermetic. You can't call any code that would have a side-effect (other than burning compute resources) or get data that wasn't part of your initial input.
It could make a of sense as a "contract language", or as intended: part of a build system.
I love Starlark. I was a major implementor of it at VGS (the repo is open: https://github.com/verygoodsecurity/starlarky). It had unique distinct features that made it much easier to control and sandbox than many other languages out there.
I even built a codemod library that does a very basic python -> starlark so that one can develop using python ecosystem libraries and just copy & paste into a secure execution environment. It was a huge success at my last company.
I'm very thankful to Laurent Le-brun and Alan Donovan -- both of whom are exceptional engineers that I learned so much from. I thought I was skilled but both of those individuals are just on another level.
To those pointing out that it's dynamically typed, meta's rust implementation - that they use in buck2 - supports type annotations.
Related:
Starlark Language - https://news.ycombinator.com/item?id=40700549 - June 2024 (49 comments)
An Overview of the Starlark Language - https://news.ycombinator.com/item?id=40573689 - June 2024 (49 comments)
(The) Starlark Language - https://news.ycombinator.com/item?id=39457410 - Feb 2024 (1 comment)
RepoKitteh: Github workflow automation using Starlark - https://news.ycombinator.com/item?id=26674781 - April 2021 (7 comments)
I ran into the language very differently than many posts here. The Tidbyt [0], a retro-style smart display designed to provide at-a-glance information on the weather, sports scores, transit schedules, etc., uses it to enable people to create their own custom displays.
For those purposes, it is simple. The simplicity reminds me of Lua. It is a perfect choice for the device.
This is interesting as I was evaluating starlark few days ago. The fact that has a customizable implementation in golang, and a python similar syntax makes it an interesting choice for agents generated code.
https://tilt.dev/ also uses Starlark.
Starlark (originally Skylark) is the configuration/extension language of Google's build tool Bazel.
It's a bespoke Python subset... functions but no recursion, dicts but no sets, etc.
It's also been adopted by the latest version of Buck (Meta's Bazel analog).
I use it daily.
It's an option for lightweight embeddable scripting language, with implementations in Java and Go. If you want Python familiarity, consider it as an option.
I feel like no other embedded scripting language will ever surpass lua. Neovim, roblox and all my projects that needed scripting support use lua, its my first choice.
Can you use Starlark inside Python? We have a rules engine where we'd like the rules themselves to be maintained outside the regular codebase, but we'd rather not invent a new DSL for them.
> Deterministic evaluation - Executing the same code twice will give the same results.
What’s this all about? Don’t most languages?
Starlark is definitely a mixed experience IMO, from my 7 years working with it in Bazel
On one hand, having a "hermetic" subset of Python is nice. You can be sure your Bazel starlark codebase isn't going to be making network calls or reading files or shelling out to subprocesses and all that. The fact that it is hermetic does help make things reproducible and deterministic, and enables paralleization and caching and other things. Everyone already knows Python syntax, and its certainly nicer than the templated-bash-in-templated-yaml files common elsewhere in the build tooling/infra space
On the other hand, a large Starlark codebase is a large Python codebase, and large Python codebases are imperative, untyped, and can get messy even without all the things mentioned above. Even though your Starlark is pure and deterministic, it still easily ends up a rats nest of sphagetti. Starlark goes the extra mile to be non-turing-complete, but that doesn't mean it's performant or easy to understand. And starlark's minimalism is also a curse as it lacks many features that help you manage large Python codebases such as PEP484 type annotations, which also means IDEs also cannot provide much help since they rely on types to understand the code
For https://mill-build.org we went the opposite route: not enforcing purity, but using a language with strong types and a strong functional bent to it. So far it's been working out OK, but it remains to be seen how well it scales to ever larger and more complex build setups