Live data from Hacker News

Pkl, a Programming Language for Configuration

pkl-lang.org

451–460 of 598 posts

Re: Pkl, a Programming Language for Configuration

#451

Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futamura Projections. We have been working with Apple on this for a while, and I am quite happy that we can finally read the sources! https://github.com/oracle/graal/tree/master/truffle Disclaimer: graalvm dev here. Edit: typo

> ...GraalVM Truffle framework... Futurama Projections... I know it's partly on me for not knowing the domain, but I honestly suspected somebody is trying to make fun of me with some concentrated technobabble. Especially since I wouldn't expect the topic (configuration languages) to require complex mathematical machinery to work with. Now I have something interesting to dig into.

> Futamura

not Futurama :D

Re: Pkl, a Programming Language for Configuration

#452

Earlier quoted context omitted.

I am sorry if the wording of my opinion has offended you. My parents most likely would have complained that they'd need 58 floppy disks to run this programming language. :)

It's not that it's offensive, it's just not conducive to constructive dialog. "Enshittification" has rapidly come to mean nothing more than "changing in ways I don't like", just crasser.

Ok, I'll avoid that term in the future, then.

Re: Pkl, a Programming Language for Configuration

#453
post #245

Earlier quoted context omitted.

Guess the obvious question is why don’t you want types in your config language? Pushing all the validation to parsing state just makes it hard to write valid config, because you only know if the config is valid when you feed it into your program. Having the ability to pull all that validation forward, and into your IDE, means you can be told about invalid config as you’re writing it. To me the idea of only wanting to…

Yeah, generally, you want to validate as early as practical... catching problems sooner is better than later. I think the problem might be separation of concerns... pkl comes in early, and by design is separated from your app and the details thereof. It seems good for validating high-level or external configuration constraints. But suppose you have some constraints based on implementation details of your app. Now you…

Hmm isn’t pickle designed for exactly this use case? External config module deps you pull for overall config validation.

E.g. so you always write valid k8s manifests.

And then you can extend them with your own additional validation rules for what you think your app needs? I’ve just skimmed the docs but it seems it allows you to be as loose or as precise as possible, plus packaging and publishing those rules for others to use.

Seems kinda awesome.

Re: Pkl, a Programming Language for Configuration

#454

I'm curious about the language "bindings" for reading Pkl from Java, Kotlin, Swift, and Golang. At first I thought these were completely independent implementations of the language, since they read from Pkl source and not some intermediate format. However, the CLI talks talk about a "pkl server" mode that is used by the bindings. So it looks like there is a single implementation (written in some JVM language?) that i…

At some point, we'll publish more documentation about this, including instructions for how to build your own language binding.

And, it's only a sub-process right now, but we plan on also providing a C library as another way to bind to Pkl.

But if you want to learn more about how this works, feel free to connect with us on GitHub! https://github.com/apple/pkl/discussions

Re: Pkl, a Programming Language for Configuration

#455

Pkl was one of the best internal tools at Apple, and it’s so good to see it finally getting open sourced. My team migrated several kloc k8s configuration to pkl with great success. Internally we used to write alert definitions in pkl and it would generate configuration for 2 different monitoring tools, a pretty static documentation site and link it all together nicely. Would gladly recommend this to anyone and I’m ex…

[dead]

Re: Pkl, a Programming Language for Configuration

#456
post #320

Earlier quoted context omitted.

Ah sorry - that was an unintended side-effect of re-upping the original submission. I must have done some of the steps in the wrong order.

You mean you don’t have a distributed merge post microservice that emits post migration events, which are then consumed by a post owner conversion service using your existing event-driven architecture to facilitate seamless data synchronization and user notification processes??? That is not very hacker news of you from the guy who owns hacker news.

I know you're joking, but I actually think complexity like that (when mostly unnecessary) is the least hackery thing in the world. Simple and effective gives me a hacker buzz

Re: Pkl, a Programming Language for Configuration

#457

Earlier quoted context omitted.

Ah just give me typescript, I do not need to learn a new thing for configuration languages and at the end of the day the output is compatible with JSON. Typescript has all the stuff I would want: types, first class json support, an ecosystem of libraries (if you want it, I would probably not for config generation). And the tooling is amazing. Does pkl have LSP, syntax highlighting in every editor, debugger or repl?

Agreed. If we're getting the point where you're saying "it's like writing your configuration in [insert Domain Specific Language Here]" then I'd prefer to simply use that language. I understand the point Pkl is making in that "configuration won't work across DSLs so here's one language for all of them" but I don't know that that's enough motivation for people to adopt it. However, I haven't built anything cool like t…

At one time I just gave up on using any config formats and instead went back to the good old simple "use the programming language as the config file too" approach.

It's certainly not cross language capable but when your editor knows exactly what's there and what's not with auto completion from the config file, that was a superior experience than caring about cross language issues that may not even be a problem depending on the project.

If you must, you can easily make an identical copy of the config in the build process to convert it to another language.

Re: Pkl, a Programming Language for Configuration

#458

Earlier quoted context omitted.

Was about to ask if you had k8s api models available internally, and that someone should create some tool to generate that from the spec. But turns out it already exists in the open! https://github.com/apple/pkl-k8s-examples

Coming from yaml+kustomize, all those curly braces are a tough sell. It looks like they roughly double the number of lines in the file.

While I learned to accept YAML it messes up editor usage.

It is so sensitive that basic text editing like copy and paste, tab, in/decreasing indent never quite do what I expect in IntelliJ.

I paste parts of yaml into another yaml and it ends up somewhere unpredictable.

Re: Pkl, a Programming Language for Configuration

#459
post #435

Earlier quoted context omitted.

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.

Especially since k8s allows using arbitrary labels for plugins, effectively creating „stringly typed“ programming.

Nobody is stopped from compiling code, converting it to base64 and storing it into a label for later execution.

Arbitrary parameters like this are the opposite of a unifying abstraction.

That ingress-behavior wasn‘t defined but pluggable to suit existing load balancers also broke the abstraction.

Re: Pkl, a Programming Language for Configuration

#460
post #182

Earlier quoted context omitted.

new game: llm hallucination, attempt at humor, or legitimate technical explanation.

Too close to the "reliably solvable by simple heuristic" end of the spectrum to be a good game: if the text is short it's probably a joke, if it is a very long wall of words it's LLM and anything of somewhat reasonable length can only be a legitimate technical explanation, no matter how unlikely.

> and anything of somewhat reasonable length can only be a legitimate technical explanation, no matter how unlikely.

thanks, that will help improve the output.

Post reply on HN