how about compare with hocon ？

[shalk]

Hello everyone
I just looked into pkl and found it to be both simple and powerful.

I also read the comparison on the pkl website:
https://pkl-lang.org/main/current/introduction/comparison.html
How does it compare with HOCON?
https://github.com/lightbend/config/blob/main/HOCON.md

In my opinion, HOCON is more human-readable than JSON and not as complex as Jsonnet or HCL.

AFAIK，HOCON do not have a package manager.

Also, it would be better if there were some side-by-side comparison cases with it on the website.

[HT154]

Hi there! I agree that this is probably to valuable to document somewhere. In lieu of adding it to our docs, here's my very brief summary of the differences:

• HOCON's type system is JSON's type system: there is a limited selection of data types and everything is dynamic. Pkl has a rich type system that allows defining schemas for configuration with user-defined classes, more built-in types (eg. Bytes), and a full-featured standard library.
• Evaluating a Pkl module validates it against its declared schema; a successful evaluation guarantees that all output fields have the expected type and meet any declared constraints. Conversely, HOCON does not provide this kind of validation, which must be implemented (and tested!) in application code or in an external schema format like jsonschema. This means that using HOCON (or YAML or JSON or properties, etc.) requires more maintenance time/effort/overhead for the same level of functionality.
• Editing Pkl comes with a lot more help: pkl-lsp and pkl-intellij provide great editor experiences like auto-complete, type checking, and code formatting.
• HOCON is a largely-static config format like YAML with some affordances for including external files/URLs and referencing environment variables. In contrast, Pkl is a complete programming language with classes, methods, and control flow.
• Pkl schemas and library code both benefit from reuse, which is the motivation for Pkl's package management system. The core team maintains a suite of packages for common infrastructure systems like Kubernetes, Prometheus, and more.
• HOCON seems to be (primarily?) targeted for application embedding. Pkl supports this usage as well, but can also be used "standalone" with just its CLI to produce flat configuration files. A great example of this is Pkl's configuration for GitHub actions (see .github/index.pkl in this repo)! Pkl has built-in support for rendering to several common formats and can be extended in-language to support many more.
• One nice feature HOCON offers that Pkl does not is "Paths as keys". This can be really useful for reducing the amount of code needed to express deeply nested structures. We call this feature "flat member syntax" and we're working on some prerequisite language internals that will enable it!

So TL;DR, Pkl and HOCON have different scopes and thus solve different problems. We tend to think (and try to make) Pkl the right solution for configuration in most cases, but there are certainly tradeoffs in complexity and flexibility to account for!

[shalk]

Thank you for your so detailed reply! This information will be very useful for my investigation report.