Comment by lihaoyi | Hacker News Reader

Comment by lihaoyi | Hacker News Reader

Parent Full thread

Author here! The issue here is that builds, and many other "just configuration" scenarios, are fundamentally complex. So many projects that start off as "just XML" or "just YAML" end up implementing their own half-baked programming language interepreter inside of their XML/YAML/JSON/whatever.

Examples:

* Github Actions Config Expressions https://docs.github.com/en/actions/writing-workflows/choosin...

* CloudFormation Functions https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

* Helm Chart Templates https://helm.sh/docs/chart_best_practices/templates/

There is a reason why Bazel went with Python/Starlark, why Pulumi and CDK and friends are getting popular. Fundamentally, many of these use cases look surprisingly like programming languages: maybe not immediately, but certainly after you've dug in a bit. And having a properly designed purpose-build programming language (e.g. StarLark) or a flexible general purpose language (e.g. Typescript, Kotlin, Scala) does turn out to be the least-bad option

I agree that Bazel did pretty well with Starlark, but the reason that’s sane is because it’s not Python, though the syntax is similar. It avoids getting into trouble with people using Python language features that would result in upgrade hell and annoy other programmers who aren’t Python experts.

(Though, debugging complicated Starlark code can still be difficult.)

So why not use Starlark? :)

Just wanted to mention that there are much better config languages than Starlark by now: CUE, Pkl, etc.

I was going to mention Cue, but I’ve only read about it, not used it, and couldn’t actually say whether it’s better.

I'm afraid that no current config language is an obvious fit for Mill. That's because Mill is fully reactive and doesn't distinguish between build configuration and execution by design.

Why do you call these other languages “better”? They’re different, but I’m not sure why either of the one’s you mentioned would be better for this use case.

Modern config languages offer strong validation and advanced IDE support, which is essential for a great user experience.

https://pkl-lang.org/intellij/current/highlights.html

Starlark is great, but so is Scala. People underestimate how big the ecosystem is even for a niche language like Scala:

- Global publishing and distribution infrastructure

- IDE support in multiple IDEs

- A huge ecosystem of third party packages, both Scala and Java

- An excellent Scala standard library and Java standard library

- Good performance.

- Tooling! Jprofiler is great. Others use Yourkit or JFR.

- Mill leans havily on Scala's FP/OO hybrid style with types, while starlark provides none of that and is purely untyped procedural code

> end up implementing their own half-baked programming language interpreter inside of their XML

Greenspun's tenth rule.

Reply on news.ycombinator.com