FRESH

Hacker News

Starlark Language

78 points by zerojames

by laurentlb

0 subcomment

Related recent discussion:
An Overview of the Starlark language - https://news.ycombinator.com/item?id=40573689

by oldmanhorton

1 subcomments

Lots of positive comments here that are mostly correct, but I will say that if you're working with more junior or just less technically passionate people, Starlark is a lot for them to wrap their heads around. "Python, but not", no Starlark.exe (always hosted in different exes that provide different functionality), poor editor highlighting/intellisense, and the concept of writing configuration in the same language which interprets that configuration are all hurdles that I've found some have difficulty with. DSLs encoded in yaml and JSON have a lot of the same problems, but I still get a lot of feedback that Starlark feels more complicated.

by danpalmer

2 subcomments

Something I didn't appreciate before working in a very large tech company was just how much of a difference a good configuration language makes. In my previous company, configuration was a mix of YAML, JSON, and hardcoded values in Python. While this worked fine, deficiencies in YAML/JSON meant that we often had additional tooling around those files to generate more config.
At Google, languages like Starlark are used to build entire software stacks that run at configuration-time. Configuration with a base language, libraries, domain-specific languages, team-specific utilities, conventions, linters, and the whole thing gets built into a package that can be run by some much more general server.
That level of complexity is unnecessary in many places, but the one thing I would take on elsewhere is to pick a good, capable, config language early, and then use it for as much config as possible. Starlark is a good option if you like Python-ish stuff, Jsonnet is also pretty nice.

by itayd

0 subcomment

by forrestthewoods

2 subcomments

Having used Starlark somewhat extensively with Buck2 I'm like 32% sure it is a mistake. Vanilla Python or ideally C# should be used instead.
The biggest issue is I want first class debugger support. Language support is fiendishly complex. It's impossible to reason about without a step debugger. printf debugging is insufficient. I should be able to debug as trivially as "attach to process" and F9'ing a breakpoint.
I'm not convinced the restrictions imposed by Starlark actually matter. There's so many compiler toolchains that can introduce non-hermetic behavior that I don't think much is gained from locking down the scripting language. We're professionals here, it's ok to say "don't do that".
Buck2 is pretty rad overall. I kinda wish it was the industry standard. But that will probably never happen because adding support for new languages is so complex it requires a non-trivial team of FAANG engineers to support full-time.
I tried and failed to add Jai support to Buck2. The Starlark rules are too complex and too impossible to understand. Dynamic types are a nightmare to decipher. Compiling programs isn't actually that difficult! Figuring out how to induce the machinery to run the commands I need turned out to be insurmountable. :( Google and Meta are both hamstrung by trying to carry forward a decade+ of old build definitions to new systems. There's significant baggage.

by ManBeardPc

0 subcomment

I just started a new position as a build engineer to help migrate a huge codebase to Bazel at a big automotive company. As there are a lot of custom proprietary tools I’ll probably write quite a bit of Starlark. So far it looks nice, let’s see how my experience will be in a couple of months.

by lopkeny12ko

3 subcomments

Starlark is one of those things that reminds you about how trends in computing are totally circular. In the early days, people strung together configuration through imperative shell scripts and Lua scripts and the like. Then there was this massive push toward declarative configuration DSLs and configuration-as-code and we got Terraform and a whole mess of YAML in every "cloud-native" open source project. And now we're shifting back to writing configuration imperatively as regular programs with Starlark and similar languages. No doubt another 5 years from now we'll just switch everything back to declarative once programmers get bored of the current trend.

by yeputons

3 subcomments

Fun fact: execution is not only deterministic, but guaranteed to terminate eventually. I.e. no indefinite loops or recursion is allowed. Quite useful for a configuration language. Of course, that means it's not Turing-complete.

by break_the_bank

1 subcomments

We used Starlark for all of its properties and built a tool[0] that allows you to spin up containers in an imperative programming way on Docker and Kubernetes through Starlark!
It can be pretty cool as you can pass in arguments and get a different set of services based on what you pass in. I like to think of it is an "exe" for a distributed system.
[0]https://github.com/kurtosis-tech/kurtosis

by badoongi

1 subcomments

I've been working through a legacy starlark codebase recently. My take is that the language, and the bazel phased execution model, makes it very challenging to debug.
One example: as far as I can tell there is no way to get the Starlark call stack, this is a tool you really want for printf debugging (which is your main debugging tool with Starlark), I can't find it right now but I believe I saw them say that they don't want to give access to the call stack for performance reasons which I find odd - is the bottleneck in slow bazel builds close to be starlark execution time?
Also looking at a non trivial Starlark codebase that didn't mature well, I can't help but wonder if it wasn't better to not give engineers as much flexibility for their build configuration, yes, they'll have some copy pasted configuration snippets that could look tighter with a macro, but you are less likely 5 years later to look at a monster that is slow and hard to debug.

by nhumrich

4 subcomments