What does HackerNews think of starlark-go?
Starlark in Go: the Starlark configuration language, implemented in Go
Starlark is so, so good by comparison to Cue.
Bazel's configuration language is called Starlark[0] (used to be Skylark). It's not a strict subset of Python. It has implementations in Java[1] and Go[2]. I haven't had a chance to use it yet, but it seems very useful as a general-purpose scripting language, especially for embedding into tools.
[0] https://docs.bazel.build/versions/master/skylark/language.ht...
[1] https://github.com/bazelbuild/bazel/tree/master/src/main/jav...
https://github.com/google/starlark-go
https://github.com/starlight-go/starlight
It seems to be used by the Delve debugger for example:
https://github.com/go-delve/delve/blob/master/Documentation/...
I expect the trend of YAML configuration with templating hacks on top (which comes in at least two varieties: templates producing YAML as text like in Salt and templates inside YAML leaf nodes like in Ansible) to be seen as the early 2010s equivalent of growing an ad hoc programming language on top of XML. It tends to happen, since complex configuration needs to reuse values and contain expressions and it is easy to implement in a backwards-compatible way. The users will appreciate it if they had nothing before, but it locks them into a path of writing code (because it is code) with an ugly error-prone syntax, complex two-layered semantics, and little abstraction. I have got good mileage out of Ansible, but I would enjoy using it a lot more if the playbooks were written in a restricted subset of Python, for example.
You can do better without types, too. Writing Scheme, Lua, Tcl, etc. code as configuration even predates the XML craze. (Tcl and Lua code can be sandboxed and limited in the number interpreter instructions and wall-clock run time. Tcl in particular has extensive sandboxing capabilities built in with "safe interpreters".). The appearance of restricted configuration languages like Starlark (https://github.com/google/starlark-go), Jsonnet (https://jsonnet.org/), and Dhall (https://dhall-lang.org/) looks like a reaction to the trend of JSON/YAML templating, and it is a welcome reaction.
The idea is to have a "safe" and "unsafe" Python (ala Rust) according to some guarantees. Proving termination of program is hard, but it is doable if dev time is dedicated to it, and algorithms are well chosen.
That way, some core libraries could be rewritten and give stronger guarantees.
The idea is used in https://github.com/google/starlark-go which is a subset of Python. People who are used with Python can use it to write imperative config files, and the files are guaranteed to not mess with sensible stuff
edit : some starlark design choices explained : https://github.com/bazelbuild/starlark/blob/master/design.md
And sadly, to use. Nix is a great idea but it could do a lot to help itself out if it ever wants to become more than niche:
1. Use a more approachable package definition language; Starlark (https://github.com/google/starlark-go) or Lua would probably be great choices.
2. Make it reasonable to figure out what the "type" of a package dependency is so we can figure out how to use it and/or find its source code
3. Document package definitions. We document source code in typed languages; Nix expression language is untyped and generally less readable--why not document it?
4. Nix tools have a `--help` flag that only ever errors with "cannot find manpage". This is just user-hostile.
5. Using almost-JSON for the derivation syntax, but then providing a "pretty printer" that keeps everything on one line but with a few more space characters.
6. Horrible build output--everything for every build step (megabytes of useless gcc warnings) gets dumped to the screen. Contrast that with Bazel and company which only print errors.
Plus a long tail of other things I'm forgetting.
> Starlark is a dialect of Python intended for use as a configuration language