4 ms·

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 X

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/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions https://docs.github.com/en/actions/writing-workflows/choosin... * CloudFormation Functions https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui... * Helm Chart Templates https://helm.sh/docs/chart_best_practices/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

skybrian 2y ago
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? :)
- mrudolph22 2y ago
  Just wanted to mention that there are much better config languages than Starlark by now: CUE, Pkl, etc.
  - skybrian 2y ago
    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.
    - mrudolph22 2y ago
      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.
  - vamega 2y ago
    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.
    - mrudolph22 2y ago
      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 https://pkl-lang.org/intellij/current/highlights.html
- lihaoyi 2y ago
  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
ackfoobar 2y ago
> end up implementing their own half-baked programming language interpreter inside of their XML Greenspun's tenth rule.

skybrian 2y ago

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? :)

mrudolph22 2y ago
Just wanted to mention that there are much better config languages than Starlark by now: CUE, Pkl, etc.
- skybrian 2y ago
  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.
  - mrudolph22 2y ago
    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.
- vamega 2y ago
  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.
  - mrudolph22 2y ago
    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 https://pkl-lang.org/intellij/current/highlights.html
lihaoyi 2y ago
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

ackfoobar 2y ago

> end up implementing their own half-baked programming language interpreter inside of their XML Greenspun's tenth rule.