Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pkl, a Programming Language for Configuration

pkl-lang.org

Post reply on HN
Print view View original

431–440 of 598 posts

Re: Pkl, a Programming Language for Configuration

#431

Post by n42 »

flir wrote: post #429
n42 wrote: post #428

Earlier quoted context omitted.

If your configurations are simple, you don’t need this. If they are not, you might. Because you have not run into the problems this has addressed in your career, does not mean that you know better than Apple how to solve them. In fact, it means like you are uniquely unqualified to solve them. Acting like you are in a severely condescending dismissal of the engineers who worked on this makes for boring conversation.

Maybe give us an example? It's an interesting question - just how complex are our biggest configuration problems today?

A team of 6 responsible for overseeing the deployment of all software in a department of 1000 to any number of deployment environments with tight budgets on durability, delivery time, and the autonomy of the teams that are writing the configuration may reach for this, or something similar, over the Windows Registry

Re: Pkl, a Programming Language for Configuration

#432

Post by Fischgericht »

n42 wrote: post #428
Fischgericht wrote: post #413

Earlier quoted context omitted.

Creating complex layers upon layers just to "solve" a very simple problem is not innovation. It's shittification.

If your configurations are simple, you don’t need this. If they are not, you might. Because you have not run into the problems this has addressed in your career, does not mean that you know better than Apple how to solve them. In fact, it means like you are uniquely unqualified to solve them. Acting like you are in a severely condescending dismissal of the engineers who worked on this makes for boring conversation.

Well, Apple is the gold standard in creating new proprietary programming languages for often just evil reasons - typically for vendor lock-in.

They invented the Objective C and Swift, and made it pretty much impossible to use any standard language to target their platforms in a cross-platform way. I can access the Windows API with any language I want. I can access the Linux Kernel API with any language I want. I can access the BSD API with any language I want. I even can use any language I want on the C64 to call native operating system functions.

So, yes, I am taking the liberty to believe I know better than Apple. TBH I don't regard this conclusion as rocket science, so no ego involved here.

Re: Pkl, a Programming Language for Configuration

#433

Post by cstrahan »

flir wrote: post #429
n42 wrote: post #428

Earlier quoted context omitted.

If your configurations are simple, you don’t need this. If they are not, you might. Because you have not run into the problems this has addressed in your career, does not mean that you know better than Apple how to solve them. In fact, it means like you are uniquely unqualified to solve them. Acting like you are in a severely condescending dismissal of the engineers who worked on this makes for boring conversation.

Maybe give us an example? It's an interesting question - just how complex are our biggest configuration problems today?

Kubernetes config is a decent example. I had ChatGPT generate a representative silly example -- the content doesn't matter so much as the structure:

https://gist.github.com/cstrahan/528b00cd5c3a22e3d8f057bb1a7...

Now consider 100s (if not 1000s) of such files.

I haven't given Pkl an in depth look yet, but I can say that the Industry Standard™ of "simple YAML" + string substitution (with delicate, error prone indentation -- since YAML is indentation sensitive) is easily beat by any of:

- https://jsonnet.org/

- https://nickel-lang.org/

- https://nixos.org/manual/nix/stable/language/index.html

- https://dhall-lang.org/

- (insert many more here, probably including Pkl)

Re: Pkl, a Programming Language for Configuration

#434

Post by shepherdjerred »

jowf8fa9sdf wrote: post #11
btmiller wrote: post #5

I was a big believer in Helm for generating Kubernetes resources until I looked up and saw that we had created an impossible-to-validate, impossible-to-reason-about DSL in our values.yaml and that's when I realized we were at the end of our rope with Helm. We switched to Pkl for our Kubernetes resource generation -- it's delightful to maintain and reason about our deployments before execution time :)

After spending 5,000+ hours in helm charts, I still hate helm. I've looked at cdk8s but I hate the tsconfig culture, why can't it be simple like Go?

Try Deno with CDK8s! It's such a fantastic experience. Here's a repo for my home server: https://github.com/shepherdjerred/servers/tree/main/cdk8s

Re: Pkl, a Programming Language for Configuration

#435

Post by flir »

cstrahan wrote: post #433
flir wrote: post #429

Earlier quoted context omitted.

Maybe give us an example? It's an interesting question - just how complex are our biggest configuration problems today?

Kubernetes config is a decent example. I had ChatGPT generate a representative silly example -- the content doesn't matter so much as the structure: https://gist.github.com/cstrahan/528b00cd5c3a22e3d8f057bb1a7... Now consider 100s (if not 1000s) of such files. I haven't given Pkl an in depth look yet, but I can say that the Industry Standard™ of "simple YAML" + string substitution (with delicate, error prone indentat…

You're absolutely right, k8s is a pig.

Re: Pkl, a Programming Language for Configuration

#436

Post by mbo »

lclarkmichalek wrote: post #46

In a competition with sky/starlark, I feel skylark would win here. “Safe subset of python” is what a lot of people presented with this problem want, and skylark gives them almost exactly that. OTOH, curious to see what advantages Pkl gains from not having the constraints of maintaining familiarity with another language.

My employer uses a combination of Protocol Buffers (for the config schema definition) and Bazel/Starlark (for concrete instantiations). Configs are validated at build time and runtime using CEL (https://github.com/google/cel-spec).

Re: Pkl, a Programming Language for Configuration

#437

Post by H12 »

bioballer wrote: post #374
H12 wrote: post #318

I'm having a little trouble understanding the problem(s) Pkl is trying to solve. After reading the title, my assumption was that Pkl was yet another newer, better configuration language (a la TOML), but now that I've read the article, it sounds like it's more a language for _generating_ config. Unless I'm mistaken, it sounds like an abstraction on top of your config files meant to help you build & re-use configuratio…

> 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 t…

Thank you so much for the explanation!

I see much more clearly how something like this could be extremely useful.

Re: Pkl, a Programming Language for Configuration

#438

Post by bioballer »

Fischgericht wrote: post #432
n42 wrote: post #428

Earlier quoted context omitted.

If your configurations are simple, you don’t need this. If they are not, you might. Because you have not run into the problems this has addressed in your career, does not mean that you know better than Apple how to solve them. In fact, it means like you are uniquely unqualified to solve them. Acting like you are in a severely condescending dismissal of the engineers who worked on this makes for boring conversation.

Well, Apple is the gold standard in creating new proprietary programming languages for often just evil reasons - typically for vendor lock-in. They invented the Objective C and Swift, and made it pretty much impossible to use any standard language to target their platforms in a cross-platform way. I can access the Windows API with any language I want. I can access the Linux Kernel API with any language I want. I can…

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

Post reply on HN