Live data from Hacker News

Pkl, a Programming Language for Configuration

pkl-lang.org

471–480 of 598 posts

Re: Pkl, a Programming Language for Configuration

#471

What happened to generating config from templates? Like puppet/chef/ansible? Then it doesn't much matter what configuration format is used, as it is all generated from a common template. Systems like pkl and skylark live on their own and isn't well integrated with systems outside it (for example, an object inside a configuration might want to generate a log source definition in the central logstash config, or a new o…

String templates are not type safe and they are super easy to mess up data escaping, by not closing a quote or even worse: deal with yaml indentation.

Integration with resource creation shouldn’t be needed. If you look at terraform it actually does so and it’s surely nice, but that’s not strictly necessary, it’s just a result of terraform resources themselves being configured in the same configuration language as you write your config file templates. Supporting everything also comes with compromises, like only having a half-assed understanding of how to deploy Kubernetes manifests, instead of focusing on the job of only generating them.

Re: Pkl, a Programming Language for Configuration

#472
How does this compare to HCL (Terraform)?

It has about exactly the same feature set. Declarative config, type definitions, data validators, reusable modules, variables, transforming functions, loops and other repeat primitives, reading external data like files and envvars, output and input json or yaml, IDE integration, you name it.

Much under-appreciated language btw. I hardly see it used outside TF. Here I think Pkl has an advantage of gaining adoption in applications, by generating types for the application code. Otherwise it will just stay as mystic item in the admins toolbox that others consider overkill.

Re: Pkl, a Programming Language for Configuration

#473
post #34

it's very brave to release a new configuration language with no Python support today.

Python is able to load Python code at runtime, so one can use Python for configuration. A solution doesn’t need to go looking for problems that are already solved.

Not uncommon to have a python program that loads external half-trusted configuration, that must be sandboxed in capabilities.

For in-house stuff, totally agree, just use the python code itself as the configuration.

Re: Pkl, a Programming Language for Configuration

#474

Earlier quoted context omitted.

CUPS was done by Easy Software Products, in 1997. Apple adopted it only in 2002. Swift is a language entirely in the control of Apple, mainly targeting Apples platforms. With little to no community engagement. Bonjour is not really cross platform, and not really open source either as it has lots of strings attached to the license and terms one can use it under. (I wouldn't say that Apple has done "nothing" -- but to…

HLS -- created by Apple, just about everybody uses it for streaming on the web. And I think CSS animations and transforms mostly came out of Apple; at any rate, they're very similar to the animations and transforms in UIKit that originally came from NeXT.

Apple being gung-ho to push a technology to further nail Flash to the cross whether the actual reason, at least is consistent with their MO and not some great contribution to open standards.

Re: Pkl, a Programming Language for Configuration

#476

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.

The best video I know about this stuff is "Compilers for free" by Tom Stuart (https://youtu.be/n_k6O50Nd-4). It is hilarious at one point. Brilliant.

Re: Pkl, a Programming Language for Configuration

#477

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.

Genuinely read "Futurama Projections" and figured the same. This doesn't sound real (though I fully trust it is, just sounds funny).

Re: Pkl, a Programming Language for Configuration

#478
post #414

Earlier quoted context omitted.

25 years ago admin would be responsible for one server, that they would setup and then never touch until (and sometimes after) someone hacked it. Now people are responsible for thousands of containers, and GUI simply does not scale. And the configuration of those containers is domain-specific and/or varies enough so that you cannot write a single config file and copy it over. This is why configuration management syst…

Oh yes, people DO develop stuff that is not needed. Back in the 90ies pretty much every nerd sooner or later had to write his own programming language (myself included). The difference between then and today: We did throw it away afterwards. These days every week someone spews out a new "programming language", claiming that the re-invented wheel is so much more round than the others. If fully agree that you might nee…

You are proposing to use general propose language vs domain-specific ones. I think, this discussion has been settled quite some time ago. For example, awk itself is domain-specific, built for processing text (or filed-separated) files. On the other had, m4 is as old as awk. m4 was heavily used even before autoconf (sendmail configuration is probably the best-known and possibly the ugliest application of it), for configuration, so one can argue, the need for macro expansion and rendering of configuration (as well as othe types) files was recognised even back then.

m4 just shows its age, and we’ve learned what is good (being Turing-complete) and what’s less useful (multiple output streams).

m4 could’ve evolved into m5, m6, etc., but nobody did it, instead people developed tools like jinja. One could argue, this is wrong and should’ve been evolutionary, but the point still is, domain-specific language to render configuration existed because there was use for them. Perl indeed could be such, I guess it did not happen for totally unrelated reasons. If Perl worked, Python would not gain popularity.

Pkl is not conceptually a new invention, it’s a new attempt to solve a real problem.

Re: Pkl, a Programming Language for Configuration

#479
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…

Maybe not always, but surely in most cases of too complex a config, it is a case of ad-hoc grown config, representing what one wants to actually configure badly, and/or underlying abstractions of the thing one wants to configure matching badly what one wants to do. In most cases it would be good to take a step back, or multiple ones at that, and really ask oneself: "What is it, that I actually want to configure here?" and think about why it cannot be a simpler config. What abstractions would actually make expressing that config easy.

Often one will get to a very simple config format in the end. Of course, when one has to deal with very complex formats created by others, already widespread in use, on cannot easily change the format. Maybe that is the reason we get these meta config tools.

Re: Pkl, a Programming Language for Configuration

#480
post #383

Earlier quoted context omitted.

Those sound like features that will eventually lead to major security issues.

I/O can be sandboxed via flags. For example, see these CLI flags: https://pkl-lang.org/main/current/pkl-cli/index.html#common-... And when using the different language bindings, you can specify sandboxing options directly in that library.

How many people will run a malicious config at least once without the flags? At some point it becomes a numbers game.
Post reply on HN