bioballer

Pkl is newly open sourced, but it not new. It's been used for years at Apple, and has been battle tested internally.

I'd actually say that our tooling in some ways is more mature. For example, I think our IDE experience (at least in JetBrains editors) is the best out there.

There's no "walled garden" here. We want Pkl to be useful for many developers, for a variety of purposes. Hopefully that's clear enough with Java, Kotlin, and Go being amongst the various supported language bindings. We also already support Linux, and plan on supporting Windows.

It's also open sourced under the Apache 2.0 license, which grants you the right to distribute and modify it.

Cheers

I think this is a reasonable approach if you only have one stack, and don't have a lot of config. If you have one stack, you can put all the validation, types, and everything else in your runtime application, and then you don't need to learn new languages, and everything works.

This becomes a lot more painful if your work is more polyglot. If you need to define config that needs to be shared between different applications, but they're written in different languages, you'll have a much harder time. Also, say, if you need to deploy your applications to Kubernetes, and your Kubernetes specification needs to provide config files to your application, then you'll still end up in a situation where your statically typed programming language won't help. That is where something like Pkl becomes really helpful, because you have just one place to manage all that complexity--right in Pkl itself.

> A problem space I'm familiar with is having a bunch of Terraform or Cloudformation configuration you want to share/repeat in multiple projects. Doing-so can get hairy quickly, as the path of least resistance is to copy-paste a bunch of config you barely understand from some other project, and then perform trial-and-error surgery to find and change a couple of lines to suit your project.

Yes, Pkl is meant to solve this problem. It's a single place for you to configure all your targets. Within the same codebase, you can generate static configuration, and also import the same Pkl source files into a runtime application, so you don't have to copy/paste things around.

Python isn't oriented around defining and validating data.

For example, something like: "this number is be between 1 and 10" means you have to come up with a novel way to add validation, because it isn't built into the language.

Also, Pkl is meant to be usable everywhere. General purpose languages tend to be tied to their own ecosystem--imagine telling a Go developer that they need to install Python, set up virtualenv, and run pip install so they can configure their application. We'd like Pkl to be a simple tool that can be brought anywhere, and easily integrated into any system.

Pkl is a new language for describing configuration. It blends together the declarative nature of static formats like YAML or JSON, with the expressiveness, safety, and tooling of a general purpose programming language.