In a competition with sky/starlark, I feel skylark would win here. “Safe subset of python” is what a lot of people presented with this problem want, and skylark gives them almost exactly that.
OTOH, curious to see what advantages Pkl gains from not having the constraints of maintaining familiarity with another language.
Starlark seems to be overwhelmingly bound to Bazel at the moment—searching for it, I had to follow a link from Bazel to the GitHub repo and then from there I got to the implementations and found this:
> The implementations below are not fully compliant to the specification yet. We aim to remove the differences and provide a common test suite.
This does not inspire confidence that I could use this in a project any time soon.
Meanwhile, from what I can tell Pkl has a single Truffle implementation that currently supports 4 languages, it has a syntax that is more familiar to me as a non-Python dev, it has static typing, and it has a dedicated plugin in most IDEs (whereas Starlark just says to install the Bazel plugin). Maybe Starlark is more appealing to people writing Python or already using Bazel, but for the rest of us there's no contest right now.
Never used Bazel in my life, so while I can appreciate your passion, I guess I don't share your perspective. Generally the pattern I've seen has been providing a skylark interface to allow folks to define rules or configurations, which are then consumed through by whatever service via starlark-rust or similar implementations.
Step two of installing Copybara is to install Bazel [0], so that doesn't exactly contradict my claim that if you're not already using Bazel you probably won't use Starlark.
> Copybara doesn't have a release process yet, so you need to compile from HEAD.
Looks like there's an Arch Linux build maintained by... somebody, but if you're not on Arch then you're going to be building Copybara with Bazel. That this works for them suggests to me that their community has a significant amount of overlap with the Bazel community, so it's not good evidence of Starlark being used outside of the Bazel world.
Lots of projects developed at Google use Starlark. Copybara is one of them. That's where the connection comes from.
Many other companies are also adopting Starlark for their own needs. For example, Meta has invested a lot in Starlark and published their implementation (https://developers.facebook.com/blog/post/2021/04/08/rust-st...), although they don't use Bazel at all.
Starlark was first created for Bazel. The organic user growth comes from people who have seen and used the language, so often Bazel users. But it doesn't have to be.
Agree - one of the things we've found using Starlark at Kurtosis is even the small jump from Python to Starlark makes people think, "What's this Starlark? I don't want to learn a new language", and we have to show them how not-a-new-language it is. I can't imagine bringing a truly new language like Pkl to folks and having them enjoy it.
I thought the same thing with the Godot game engine's GDScript. Aside from a few class-level implementation details (IIRC, it's been a while) it's essentially Python, syntactically. "Ugh... If I'm going to learn a new scripting language it's not going to be application-specific... Oh NM."
My employer uses a combination of Protocol Buffers (for the config schema definition) and Bazel/Starlark (for concrete instantiations). Configs are validated at build time and runtime using CEL (https://github.com/google/cel-spec).
OTOH, curious to see what advantages Pkl gains from not having the constraints of maintaining familiarity with another language.