Comparison with other configuration languages?

[neongreen]

Hi!

Any thoughts on how Pkl compares to

• Dhall (https://dhall-lang.org/)
• Nickel (https://nickel-lang.org/)
• jsonnet (https://jsonnet.org/)
• CUE (https://cuelang.org/)?

[dbohdan]

I have found "Pkl vs. Other Config Languages" in the documentation.

I would like to know whether Pkl is Turing-complete for my list. Is "comparatively powerless" a yes?

[andrewcrook]

May be people can explain differences from their experiences and build a summary from those discussions? Don't forget this will need updating as any differences develop further.

[andrewcrook]

What about Nix?
I know it's also a package and an environment manager but it is also "configuration as code" and builds configuration files.
It can also use templates and parse different configuration file types.

[dbohdan]

@abhibeckert Thanks for the suggestion. I agree that the syntax could be called something more precise.

Some features of the language, like "\(foo)", definitely come from Swift. However, it is isn't all Swift: for generators require parentheses, and there is a new keyword. The use of local resembles Lua. Could someone tell me what other languages inspired Pkl's syntax? TypeScript? Scala and Kotlin?

[bioball]

Could someone tell me what other languages inspired Pkl's syntax? TypeScript? Scala and Kotlin?

I can't really give you a definite list, but, some of our inspirations for syntax were Dart, Kotlin, and Swift, Scala, and Kotlin. And yeah, some of our grammar purposefully follows Swift (strings are almost the same in Pkl and in Swift).

[holzensp]

Don't forget Newspeak! https://newspeaklanguage.org (not so much syntax, but name resolution)

[bioball]

We definitely need to flesh out our comparison page a bit.

But, here's some rough thoughts for now:

Nickel, Dhall and KCL are the closest in terms of language design. CUE has a different philosophy (types are values, values are types). Jsonnet is also similar, but lacks the ability to express types.

I think we have the best IDE experience; it's been around for years and has been polished over time. But, we only have IDE-like editing in JetBrains editors for now, at least until we provide an LSP.

One of the things that makes us unique is that we try to target both config generation, and integration into an application. I'm not aware of any other config language that provides codegen for so many different stacks; and our list of supported languages will grow over time.

CUE's design is really cool, and is built on some principles that Pkl chose not to have (no turing completeness, and object merging is commutative). On the other hand, Pkl is more focused on ergonomics (we have classes, functions, etc), and writing in Pkl is perhaps more intuitive because of this. And CUE is lacking the IDE-like experience that Pkl provides.

[bronze1man]

thanks! pkl's Ide support is great in goland !

[salotz]

Latest CUE release has the first experimental LSP release with it: https://github.com/cue-lang/cue/releases/tag/v0.8.0

[Peefy]

Hi, this is the author of KCL language. I am glad to see that Pkl is open source. I have read through the Pkl documentation and still really like it. Add some similarities between KCL and Pkl here:

• Language features: schema, validation, immutability, etc
• Multi language binding, KCL provides binding for Python, Go, and Java, etc.
• Multiple IDE plugin support: NeoVim, VS Code Based LSP.

[bioball]

Hi Peefy, nice to hear from you! I’ve been admiring what you’ve done.

[yannham]

Hi, Nickel developer here. Nice to see the configuration language family growing like this! Pkl is very new to me, so I can only give shallow impressions (which might even be wrong, please forgive me if it's the case), but at a first glance:

• As mentioned in the accepted answer, I also think Nickel, Jsonnet, KCL and Pkl, albeit different, could be put in the same large category of Turing-complete configuration DSLs supporting the JSON data model with full-fledged functions and other niceties. CUE is a bit different (it's purposely much more restricted), Dhall isn't far but isn't Turing complete
• Amongst those languages, I think Nickel, KCL and Pkl are even closer (beside the fact that they share a lot of common letters and sounds 😛 ). They all rely on first-class data validation to make sure the produced configuration is correct with respect to some schema, are dynamically typed or gradually typed for flexibility (as opposed to Dhall), and allow late-bound self-references and overriding in the configuration graph (meaning some values can depend on others, and are automatically updated if one of their dependency's value is overridden)
• It seems to me that Pkl - like Jsonnet - adopts the style of object-oriented programming, while Nickel comes more from the functional programming design space. Pkl relies on inheritance and late-binding, which isn't commutative (the last overwrite wins), while Nickel (and I believe KCL, @Peefy please correct me if I'm wrong) rather relies on merging, as in CUE. As another example of the functional programming heritage, I'm implementing extended pattern matching and (structural) algebraic data types as we speak.
• Nickel has a purely statically typed fragment with type inference. That is, you can drop a type annotation like map_dict : forall a b. (a -> b) -> {_ : a} -> {_: b} and the body of the function will be typed as in say Haskell, OCaml, Rust, etc. The type system is structural to better accommodate dynamic JSON-like data structures. Static types work together with so-called contracts, which are like types and use the same syntax but are checked at runtime (and can thus be user-defined). I can be wrong here, but Pkl types are documented as being validated at runtime, and thus don't seem to be static but rather to be equivalent to Nickel's contracts.
• I think Nickel has a very decent LSP, with the usual features package, and some effort in particular have been put in contextual auto-completion. I must admit I don't know yet how this compare to Pkl's Jetbrains support, although runtime validation (contracts) isn't reported in the Nickel LSP as of today, while Pkl seems to already have this feature implemented. (EDIT 13.03.24: contracts are now automatically checked in the Nickel LSP since 1.5.0)

[bioball]

Hey yannhamm, nice to hear from you!

Yeah, I’d agree, Pkl is designed to be relatable to folks coming from OO languages. Also, one of the design principles is that the language syntax is designed to be statically analyzable for type checks, but in practice it is runtime checked.

[BenjyWiener]

Also, one of the design principles is that the language syntax is designed to be statically analyzable for type checks

Are there plans for a static analyzer?

[translatenix]

Are there plans for a static analyzer?

I believe the IntelliJ plugin has a static analyzer. I’m getting type and constraint errors even though I haven’t configured the Pkl CLI.

[holzensp]

@translatenix is correct; there is a (best-effort!) static analyzer in pkl-intellij.

[smithamax]

As an outside observer to this space, a comparison to Starlark would also be nice. As far as I can tell Starlark doesn't have types, this seems to be the standout difference, but a general comparison would be great.

[acalvino4]

would be nice to see toml on the comparison page as well

[Malix-off]

JSON, TOML, and YAML are fundamentally different as they are static config formats

See https://pkl-lang.org/main/current/introduction/comparison.html#static-config-formats

The only thing pkl would have to add in that page is "TOML" in the shortcomings of each points where TOML applies

[Malix-off]

See #337

[salotz]

Questions for differences with CUE are:

• Support for constraints and other "logic programming" type features (I'm guessing no because of Turing incompleteness)
• are overrides forbidden (i.e. in CUE its an error to set a concrete value in two places)

As for code-gen its not built into CUE but there are things being built on top of it to support this: https://github.com/hofstadter-io/hof