Pkl, a Programming Language for Configuration

The experience with LSPs is quite underwhelming compared to what a native language plugin in IntelliJ can do. That isn’t to say the approach is bad, but it’s definitely a trade off.

This feels like a strict superset of hashicorp's HCL with strong typing and include statements. Once again, Apple has released a piece of tech which is innovative in its ergonomics perhaps, but ultimately a copy of a predecessor. This is becoming a habit of theirs and has only developed recently.

Unpopular opinion: yaml is almost as close to perfection as can be gotten. The only thing we could do to make it better is remove features.

They got some things really right. Targeting dynamic languages over static ones is the right choice, though a difficult one. 64-bit floats written in decimal notation are the goodest lowest common denominator we have (sorry), and the ability to embed valid documents in other documents (multiline strings prefixed only with white space) is a game changer. JSON compatibility is controversial, but ultimately very useful.

There are problems that are caused by too many features. The Norway problem is caused by too many features. References and splices are cool but generally confusing. That people do not use tags on their data 99% of the time in the wild strongly suggests that strongly typed configuration is less useful. True, there are too many different kinds of multi-line strings. Finally, if yaml were syntactically specified while preserving that white space feel, we could edit large yaml documents without having to get out our carpenter squares to figure out what level of indentation we're on. Syntactic specification will help our editors figure out what is happening while we type.

I have addressed many of these problems in a new language called NRDL while seeking to preserve the things that yaml got right[1]. I feel we should learn from the mistakes and the success of those configuration languages that came before.

1: https://git.sr.ht/~skin/nrdl

That’s a consequence of configuration languages not have proper type systems, and robust was to manipulate data.

Helm isn’t a configuration language, it’s a dressed up string templating system with ability to do kubectl apply.

> you can't guarantee your config is valid anyway if your config language can't see what class you're going to feed it to.

Obviously, but that’s hardly an insurmountable problem. We’ve had code gen and language introspection for decades.

> For you a "date" type might mean ISO 8601, but for me it might mean RFC 3339

A generic date type doesn’t come with any specific string format. ISO 8601 and RFC 3339 are both ways of representing a date as a string. Which has little to do with Date as a type.

There’s also perfectly good solutions to those problems. Use a type alias to create a date type backed by a string, with formatting constraints (such as a regex). Then people can define dates using any string representation they want!

Incidentally this is exactly what Pkl lets you do. You can use Pkl schema to define in detail how you want to validate your data using various primitives like regex. And then separately create a config template that uses those custom data types. As a dev you can choose how tightly bound your config template is to a data validation schema, define all the validation in line, or import an external module to provide you with richly validated data types.

The problem with configuration is that it’s only marginally useful to statically enforce that “this should be an IP address” or “this should be a port”

People rarely waste time because they put a number where they should have put an IP address. People waste a lot of time because they don’t know what IP address to put in there.

Look at any real life production nginx or kubernetes config and ask yourself an honest question — how much would a static type system actually help me in writing this config? We understand what types the configuration fields want — that’s trivial. We spend all of our time finding the correct values for those types.