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

251–260 of 598 posts

Re: Pkl, a Programming Language for Configuration

#251

Post by nsagent »

SushiHippie wrote: post #190

Can somebody tell me real use cases they would use this for? I've seen their usecase documentation entry. And I understand the benefits this could have. But I think I need some hands-on usecases, to fully grasp why or how I would use this. Thanks

Can't speak to Pkl, but for Jsonnet I made it possible to fully define then load neural network model architectures directly from Jsonnet config files [1], rather than relying on Python's unsafe pickle module.

Since neural networks often have many repeating features, using a traditional configuration language requires repeating the same structures a lot, whereas using Jsonnet you can use `std.repeat` instead. You can see some examples of this in the readme of my package.

[1]: https://pypi.org/project/cresset/

Re: Pkl, a Programming Language for Configuration

#252

Post by IshKebab »

bbkane wrote: post #155
IshKebab wrote: post #72

Earlier quoted context omitted.

Looks like it might fix three big issues I had with Cue: 1. The only way to use it is to run their Go CLI app to convert the Cue into JSON and then load that. That sucks. I want native support. Jsonnet does this a lot better ( https://jsonnet.org/ref/bindings.html ), and PKL at least supports 4 languages. Cue only supports Go directly. Not good. 2. Cue has a super fancy type system, but as far as I could figure out t…

Love this comment and I agree with basically everything. What are you using for configuration these days? I've fallen back to YAML because at least its already used for a lot of tools, and has comments, jsonschema support in VSCode giving IDE features, language library support, yamllint, and yq for formatting/querying/mass-updating from the CLI

Yeah I actually haven't found a great answer yet. Here's everything I've tried and why it sucks:

* JSON. No comments. Deal-breaker

* JSONC. No unique file extension so its difficult to distinguish from JSON. Poor library support due to library authors drinking the "comments are bad" koolaid.

* JSON5. This would be an excellent option IMO except that library and IDE support is not great.

* JSON6. This just complicates JSON5 for minimal benefits. Pointless.

* Cue. As described.

* Jsonnet. Pretty good option tbh! However I couldn't get the Rust library to work. It's a low level parser, seems like you can't just plug it into Serde, which is what 99% of people really want. Also I ran into the "uncanny valley" effect where you can do some things but not all. So it tricks you into writing some programmatic config (e.g. with string manipulation) but then you find you can't do that string manipulation.

* Dhall. Weird syntax (backslash to declare functions. I've also heard it is slow. Didn't try this too much.

* YAML. Obviously YAML is the worst option. However I did realise you can use it as basically JSON5 except with a different comment character, which is not too bad.

* Starlark. Actually I haven't tried this yet but it looks promising.

So yeah I have no idea at the moment.

I wonder if it would be worth defining a "YAML JSON5" format, that's basically YAML-compatible JSON5.

Re: Pkl, a Programming Language for Configuration

#253

Post by usrusr »

avianlyric wrote: post #209
kibwen wrote: post #181

I've had a good long think about configuration languages, and after a long-term on/off love/hate relationship with schemas I think I've finally concluded that I don't want rich types in my configs, thank you very much. I use statically-typed programming languages, and for my purposes I'd rather have a config language where the only types are strings, arrays, and hashmaps, and then push all type validation into the pa…

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…

One argument I might put on the cons side of AOT type validation for configs is that there will always be some invalid inputs that can't be statically checked (e.g. port number already taken), and not failing simple type errors before runtime helps keeping in mind and view whatever feedback channel exists for the runtime failure. I wouldn't consider that a winning argument, but it's not entirely without merit.

Re: Pkl, a Programming Language for Configuration

#254

Post by [deleted] »

avianlyric wrote: post #235
youerbt wrote: post #230

Earlier quoted context omitted.

My take on this is that there is not obvious reason not to, but it just so happens that typed configuration languages are not rich enough and not integrated enough to be that useful. Those languages that arrived with the JSON hype train like yaml or toml might be great for dynamic languages, where you can load them to some native object. But in statically typed languages you are gonna declare your types, in code, any…

Ah! Well this is the hole that Pkl does a very good job of filling! Being able to use Pkl code-gen to create language bindings means you can take any arbitrary Pkl schema and turn it into native structures in your language, typed based on the Pkl schema. Then you can let Pkl do all the heavy lifting of parsing and validating a specific config, and turning it into native objects in your language. So no need for double…

[deleted]

Re: Pkl, a Programming Language for Configuration

#255

Post by networked »

baq wrote: post #184
ahefner wrote: post #151

Earlier quoted context omitted.

...and yet Python people routinely fail to grasp this and end up writing ad-hoc config language interpreters on top of yaml anyway. Granted the conveniences of Python syntax for code are mostly lost when trying to express tree structured data, and yaml flips that on its head. (Mumble, grumble, something about s-expressions...)

That’s because it’s impossible to properly sandbox the config parsing. It’s also a horrible experience to debug configs. But it’s still better than templating yaml.

People interested in configuring Python software in Python should look into Starlark. There are Python bindings for two versions of Starlark: Go (https://github.com/caketop/python-starlark-go) and Rust (https://github.com/inducer/starlark-pyo3). I used python-starlark-go for a time in a project that ran on x86-64 Linux and had no problems with it. (I stopped because my project's configuration turned out simpler than expected, so I switched to TOML.)

Worth noting that it is specifically CPython that has been called impossible to sandbox. (2014 discussion: https://news.ycombinator.com/item?id=8280053.) It may be possible to sandbox PyPy. PyPy has a sandboxing feature its website calls a "working prototype" (https://www.pypy.org/features.html#sandboxing). If someone invested in it—potentially a huge effort—it could plausibly become good enough for configuration. But, IMO, Starlark is a better choice here because it was designed for isolation from the start. If you wanted to invest in Python-as-config-for-Python, a good use of your time might be improving Starlark for Python.

Re: Pkl, a Programming Language for Configuration

#256

Post by Terretta »

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.

Trivia note, the bazelbuild starlark readme example shows a rare correct implementation of FizzBuzz, with no unique case for "FizzBuzz".

https://github.com/bazelbuild/starlark

Re: Pkl, a Programming Language for Configuration

#257

Post by Spivak »

kibwen wrote: post #181

I've had a good long think about configuration languages, and after a long-term on/off love/hate relationship with schemas I think I've finally concluded that I don't want rich types in my configs, thank you very much. I use statically-typed programming languages, and for my purposes I'd rather have a config language where the only types are strings, arrays, and hashmaps, and then push all type validation into the pa…

Sounds like you and the INI guy agree here and honestly I'm coming around to it because for complex types you end up typing everything twice.

https://github.com/madmurphy/libconfini/wiki/An-INI-critique...

Re: Pkl, a Programming Language for Configuration

#258

Post by Terretta »

lolinder wrote: post #201
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.

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…

The implementations and users page mentioned above:

https://github.com/bazelbuild/starlark/blob/master/users.md

Re: Pkl, a Programming Language for Configuration

#259

Post by srcreigh »

usrusr wrote: post #253
avianlyric wrote: post #209

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…

One argument I might put on the cons side of AOT type validation for configs is that there will always be some invalid inputs that can't be statically checked (e.g. port number already taken), and not failing simple type errors before runtime helps keeping in mind and view whatever feedback channel exists for the runtime failure. I wouldn't consider that a winning argument, but it's not entirely without merit.

duplicate port number can be checked in the type system if you’re using racket, at least

Re: Pkl, a Programming Language for Configuration

#260

Post by maximus-decimus »

avianlyric wrote: post #209
kibwen wrote: post #181

I've had a good long think about configuration languages, and after a long-term on/off love/hate relationship with schemas I think I've finally concluded that I don't want rich types in my configs, thank you very much. I use statically-typed programming languages, and for my purposes I'd rather have a config language where the only types are strings, arrays, and hashmaps, and then push all type validation into the pa…

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…

Because with a real programming language you get an actual IDE, auto complete, a debugger, sane compiler errors instead of a vague helm error "invalid thingy at line 4", you can log a bad config the same way you log stuff for the rest of your program and you can't guarantee your config is valid anyway if your config language can't see what class you're going to feed it to.
Post reply on HN