Built-in fetching of http resources and reading files from the filesystem[1] combined with turing-completeness are features that I wasn't expecting from a configuration language. I wonder if the complexity this brings is justified. 1: https://pkl-lang.org/main/current/language-reference/index.h...
Nix does this too and maintains perfect caching from top to bottom.
Pkl, a Programming Language for Configuration
301–310 of 598 posts
Re: Pkl, a Programming Language for Configuration
#302However, 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 is run in a subprocess. I wish there was more documentation about how this works under the covers.
https://pkl-lang.org/main/current/pkl-cli/index.html#install...
Re: Pkl, a Programming Language for Configuration
#303Re: Pkl, a Programming Language for Configuration
#304Re: Pkl, a Programming Language for Configuration
#305Built-in fetching of http resources and reading files from the filesystem[1] combined with turing-completeness are features that I wasn't expecting from a configuration language. I wonder if the complexity this brings is justified. 1: https://pkl-lang.org/main/current/language-reference/index.h...
Nix does this too and maintains perfect caching from top to bottom.
Whereas this documentation for Pkl is entirely about that use case.
Re: Pkl, a Programming Language for Configuration
#306In 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.
Starlark seems to be overwhelmingly bound to Bazel at the moment—searching for it, I had to follow a link from Bazel to the GitHub repo and then from there I got to the implementations and found this: > The implementations below are not fully compliant to the specification yet. We aim to remove the differences and provide a common test suite. This does not inspire confidence that I could use this in a project any tim…
Re: Pkl, a Programming Language for Configuration
#307Pkl 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…
Re: Pkl, a Programming Language for Configuration
#308Re: Pkl, a Programming Language for Configuration
#309Pkl 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.
Re: Pkl, a Programming Language for Configuration
#310I've been looking for a way to have typed objects in the config to do config suggestions and type checking.. PKL looks like it can do this for us. And with the JSON output we might even be able to get there with minimal effort.
Is there anyone here with some PKL experience that would be willing to answer some technical questions re the use of PKL for more advanced, nested config?
See Lowdefy: