HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
bazelbuild
starlark
Python2018–2026
bazelbuild / starlark

starlark

Starlark Language

31Distinct people
38Mentions
0Explicit recommenders
3.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Starlark Language

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year38 dated mentions

Observed mentions: 2018-08-17 18:45:26 UTC to 2026-05-05 21:12:02 UTC.

0510152018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 14 mentions; 4 submissions, 10 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC211
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC413
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC505
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC606
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC14410
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Starlark Overview Starlark (formerly known as Skylark) is a language intended for use as a configuration language. It was designed for the Bazel build system, but may be useful for other projects as well. This repository is where Starlark features are proposed, discussed, and specified. It contains information about the language, including the specification. There are multiple implementations of Starlark. Starlark is a dialect of Python. Like Python, it is a dynamically typed language with high-level data types, first-class functions with lexical scope, and garbage collection. Independent Starlark threads execute in parallel, so Starlark workloads scale well on parallel machines. Starlark is a small and simple language with a familiar and highly readable syntax. You can use it as an expressive notation for structured data, defining functions to eliminate repetition, or you can use it to add scripting capabilities to an existing application. A Starlark interpreter is typically embedded within a larger application, and the application may define additional domain-specific functions and data types beyond those provided by the core language. For example, Starlark was originally developed for the Bazel build tool. Bazel uses Starlark as the notation both for its BUILD files (like Makefiles, these declare the executables, libraries, and tests in a directory) and for its macro language, through which Bazel is extended with custom logic to support new languages and compilers. Design Principles Deterministic evaluation. Executing the same code twice will give the same results. Hermetic execution. Execution cannot access the file system, network, system clock. It is safe to execute untrusted code. Parallel evaluation. Modules can be loaded in parallel. To guarantee a thread-safe execution, shared data becomes immutable. Simplicity. We try to limit the number of concepts needed to understand the code. Users should be able to quickly read and write code, even if they are not experts. The language should avoid pitfalls as much as possible. Focus on tooling. We recognize that the source code will be read, analyzed, modified, by both humans and tools. Python-like. Python is a widely used language. Keeping the language similar to Python can reduce the learning curve and make the semantics more obvious to users. Tour The code provides an example of the syntax of Starlark: # Define a number number = 18 # Define a dictionary people = { "Alice": 22, "Bob": 40, "Charlie": 55, "Dave": 14, } names = ", ".join(people.keys()) # Alice, Bob, Charlie, Dave # Define a function def greet(name): """Return a greeting.""" return "Hello {}!".format(name) greeting = greet(names) above30 = [name for name, age in people.items() if age >= 30] print("{} people are above 30.".format(len(above30))) def fizz_buzz(n): """Print Fizz Buzz numbers from 1 to n.""" for i in range(1, n + 1): s = "" if i % 3 == 0: s += "Fizz" if i % 5 == 0: s += "Buzz" print(s if s else i) fizz_buzz(20) If you've ever used Python, this should look very familiar. In fact, the code above is also a valid Python code. Still, this short example shows most of the language. Starlark is indeed a very small language. For more information, see: Discussions for some design choices Why Starlark was created (previously named Skylark) The specification The mailing-list: starlark@googlegroups.com Build API The first use-case of the Starlark language is to describe builds: how to compile a C++ or a Scala library, how to build a project and its dependencies, how to run tests. Describing a build can be surprisingly complex, especially as a codebase mixes multiple languages and targets multiple platforms. In the future, this repository will contain a complete description of the build API used in Bazel. The goal is to have a clear specification and precise semantics, in order to interoperate with other systems. Ideally, other tools will be able to understand the build API and take advantage of it. Evolution Read about the design process if you want to suggest improvements to the specification. Follow the mailing-list to discuss the evolution of Starlark. Implementations, tools, and users See Awesome Starlark.
Read the full README on GitHub

What Hacker News says

38 sources
This is exactly what the Starlark language was developed to solve, initially for Bazel but also used other places. It's a "full scripting language" but intentionally doesn't (in default configuration) support recursion or unbounded loops, so is deterministic and bounded execution time. I really wish more projects would reach for it as a configuration language. https://github.com/bazelbuild/starlark
In PyInfra 3.8.0
I agree with the author that YAML as a configuration format leaves room for error, but please, for the love of whatever god or ideals you hold dear, do not adopt HCL as the configuration language of choice for k8s. While I agree type safety in HCL beats that of YAML (a low bar), it still leaves a LOT to be desired. If you're going to go through the trouble of considering a different configuration language anyway, let's do ourselves a favor and consider things like CUE[1] or Starlark[2] that offer either better type safety or much richer methods of composition. 1. https://cuelang.org/docs/introduction/#philosophy-and-princi... 2. https://github.com/bazelbuild/starlark?tab=readme-ov-file#de...
In What would a Kubernetes 2.0 look like
I actually like Deno's take on things, the ability to "drop privs" (or "allow-list") is super powerful. Starlark is supposedly a limited version of python (https://github.com/bazelbuild/starlark), but what if you could say in python itself: def foo(): """use strict; use no_func_calls; use idempotent; use no_loops; ...""" ...checked python here... ...or being able to make assertions within a body of a for loop or something. I feel that programming languages need to evolve to deal with a hostile dependency ecosystem, eg: import leftpad as lp with { network: false, filesystem: false, environment: false, max_cycles: 100_000, max_mem: 10_000, ...etc... } ...this is purely arbitrary and hypothetical, of course, but programs become safer when made from safer, more-structured com
Read the rest
ponents. We're long past the "single programmer write all the code" phase, and in to the spiral of exponential code+complexity, but no programming languages give you the ability to wrestle with that complexity.
In Should programming languages be safe or powerful?
Python chained operators can be confusing, especially as it allows you to write things like: — x < y > z — a in b not in c WalterBright mentioned that D will give you an error. When designing Starlark (a derivative of Python), I also decided to give an error for this, by making the comparison operators non associative. https://github.com/bazelbuild/starlark/blob/master/design.md... I agree this Python feature can look cute, but I've found it's rarely useful and can easily be avoided.
In Interview gone wrong
The Starlark spec discusses this, and I consulted it before I wrote my comment. > It is a dynamic error for a function to call itself or another function value with the same declaration. > This rule, combined with the invariant that all loops are iterations over finite sequences, implies that Starlark programs are not Turing-complete. However, an implementation may allow clients to disable this check, allowing unbounded recursion. https://github.com/bazelbuild/starlark/blob/master/spec.md I do kind of agree with you about this, though: > At that point, just give your users a `while` loop for usability's sake. I'm generally in favor of powerful, purpose-built configuration languages, including Turing-complete ones. And the goal of assuring users that their programs will terminate at all is definitely aligned with a fuzzier goal, less forma
Read the rest
lizable, that their programs will terminate in a 'reasonable' period of time, whatever that means.
In What you learn by making a new programming language
Two big advantages. First, if you want a declarative config with limited, domain-specific options, rolling your own DSL instead of using something as complex as Python is much, much easier to implement. You're not actually going to be running the code either way, at least not in the normal way, and the Python syntax tree is pretty complicated. Second, having code that looks like Python can lead your users to believe that it is in, in fact, Python. When you're doing things like using your DSL as configuration that happens at setup time, but then actually "running" the resulting config later on, that can lead to people getting themselves into trouble - for instance, they might try to use `time.now()` and end up embedding the time of the config parser as a constant in their workflow definition. If you want to use Python as your language, you
Read the rest
probably want to define your "DSL" as a Python library, so that you can use a normal interpreter to work with it. Maybe you have library functions that return config objects, and a user's "configuration" is an arbitrary Python file with a standard function name as an entry point. But then when you want to introspect over types, you probably need to start playing games with decorators, which is tricky again, and you have to be very careful to have that evaluation step return meaningful errors. Starlark (https://github.com/bazelbuild/starlark) is an example of using Python-ish as a "configuration" language. That took an absolutely massive amount of engineering to get to be well-defined, and was only arguably worth it because they wanted a language that's a loop construct away from being Turing-complete. If they had wanted a basic declarative relationship language, they probably would have used textprotos or GCL.
In Every Way to Get Structured Output from LLMs
Having done some nontrivial Bazel/Starlark hacking, I completely agree that lightweight static types would be a good usability improvement. But I want to point out that Starlark is actually not Turing complete, which is imo one of the more interesting characteristics it has. Recursion is forbidden (https://github.com/bazelbuild/starlark/blob/master/spec.md#f...) and loops must be structural; there is no while loop or other unbounded iteration construct. Starlark is one of the more capable and mainstream non-Turing-complete languages out there, and doesn't resemble the other common ones which mostly show up in theorem provers. On the one hand I think the logic in a build system that needs to reason about incremental builds absolutely should be guaranteed to terminate, but in some particularly painful situations I've had to resort to iterat
Read the rest
ion over smart-contract-style "gas" parameters. EDIT: as a parting shot, dhall is another non-Turing-complete language in common usage, but its claim to fame is that it gets used in places that arguably shouldn't be doing any computation at all.
In An Overview of the Starlark Language

Showing the 15 most recent of 38 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.