I used Starlark for a prototype at a past job. The Go implementation was 1) pure Go (I couldn’t use Cgo), and 2) super easy to get up and running. IIRC it took me about an hour to go from “this looks promising” to “neat, it works”, given that I’d already built everything else and sorta left a hole for an interpreter to plug into.
We used Go Starlark at the RIPE DNS hackathon to prototype sandboxed scripting to run on RIPE Atlas probes. It was pretty successful. I suggested Starlark on the basis that something Python-like would be more friendly to data scientists.
It’s better than Makefiles, but the temptation to go nuts with it is high and this leads to a higher maintenance burden, not the least because testing is suboptimal.
Some aspects of starlark are hard to reason about. I eventually did (mostly) grok these bits (all related to the different phases of the execution: https://bazel.build/run/build#bazel-build) but they’re still annoying.
My frustration is that you get presented with bazel, then Starlark, and then a bunch of restrictions that are downstream of Google’s monorepo needs, which get in the way of my needs (where my project is much smaller and the phase separation stuff is not nearly as valuable).
There’s a unvierse where someone invents Bazel, but for smaller projects and it will take over the world.
Yeah, you still have to be very judicious in what you do. I’d say about 90% of software engineers at Google should never write more than trivial things in Starlark, and the other 10% better have a dang good reason to do so.
I’ve been using Starlark with Vela CI for a while now and love it for builds more complicated than what can be expressed in simple YAML. A Python library aptly called python-starlark-go helps with debugging so I have a very lightweight test runner in Python that uses the Go implementation of Starlark that Vela uses.
I used Starlark for a prototype at a past job. The Go implementation was 1) pure Go (I couldn’t use Cgo), and 2) super easy to get up and running. IIRC it took me about an hour to go from “this looks promising” to “neat, it works”, given that I’d already built everything else and sorta left a hole for an interpreter to plug into.
We used Go Starlark at the RIPE DNS hackathon to prototype sandboxed scripting to run on RIPE Atlas probes. It was pretty successful. I suggested Starlark on the basis that something Python-like would be more friendly to data scientists.
I use Starlark in conjunction with blaze (bazel) (https://bazel.build/rules/language) and am ambivalent about it.
It’s better than Makefiles, but the temptation to go nuts with it is high and this leads to a higher maintenance burden, not the least because testing is suboptimal.
Some aspects of starlark are hard to reason about. I eventually did (mostly) grok these bits (all related to the different phases of the execution: https://bazel.build/run/build#bazel-build) but they’re still annoying.
My frustration is that you get presented with bazel, then Starlark, and then a bunch of restrictions that are downstream of Google’s monorepo needs, which get in the way of my needs (where my project is much smaller and the phase separation stuff is not nearly as valuable).
There’s a unvierse where someone invents Bazel, but for smaller projects and it will take over the world.
I’m curious if you could elaborate on the restrictions that Bazel imposes, especially wrt how phase separation causes problems
Yeah, you still have to be very judicious in what you do. I’d say about 90% of software engineers at Google should never write more than trivial things in Starlark, and the other 10% better have a dang good reason to do so.
I’ve been using Starlark with Vela CI for a while now and love it for builds more complicated than what can be expressed in simple YAML. A Python library aptly called python-starlark-go helps with debugging so I have a very lightweight test runner in Python that uses the Go implementation of Starlark that Vela uses.