Live data from Hacker News

Pkl, a Programming Language for Configuration

pkl-lang.org

361–370 of 598 posts

Re: Pkl, a Programming Language for Configuration

#361

Earlier quoted context omitted.

But I have no idea how I would build a config structure for an application using Nix... It seems very powerful so I'm sure it's possible, but I just have no idea where I'd start for this specific use case. Whereas this documentation for Pkl is entirely about that use case.

I agree that there's a huge documentation and user awareness gap, but NixOS is obviously possible to configure this way so it's definitely possible. Might be room for a tool that exposes just the configuration management side of Nix in a more approachable way... on the other hand it would be a bit silly to use nix for conf files and not also for the underlying packages.

I guess it strikes me as not just a documentation and awareness gap, but a different paradigm in a more fundamental way.

I think your last sentence gets at that too: For Nix, configuration management is just one component of a broader and more powerful paradigm. And it seems to me like putting a square peg in a round hole (or as you say, a bit silly) to try to use it to solve this narrower and simpler problem.

Re: Pkl, a Programming Language for Configuration

#362

Earlier quoted context omitted.

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…

Copybara uses it

Step two of installing Copybara is to install Bazel [0], so that doesn't exactly contradict my claim that if you're not already using Bazel you probably won't use Starlark.

[0] https://github.com/google/copybara

Re: Pkl, a Programming Language for Configuration

#363

Earlier quoted context omitted.

> ...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.

Shameless self plug: Giving an introduction in this video: https://youtu.be/pksRrON5XfU?si=CmutoA5Fcwa287Yl

Gently teasing: linking a 2 hour video with "shameless self plug" definitely did _not_ help obviate the surreality.

Re: Pkl, a Programming Language for Configuration

#364
post #351

Earlier quoted context omitted.

Nix is a build & metaprogramming system, not (just) a configuration language.

Nix is a bunch of things, one of which is a configuration language.

A major difference is that Nix has no type system or schema. Pkl is typed.

Re: Pkl, a Programming Language for Configuration

#365
post #164

Having read through the the docs a little, my gut reaction is that they might be a little too much in love with the idea of having created a language that can serve both as schema definition and as minimal values carrier. It smells of unexpected failure modes through overuse [1]. But perhaps this is exactly the core feature: everybody who adds pkl to their software implicitly signs up for participation in whatever co…

It's normal for a programming language to have the ability to define types and create values of those types. Pkl is entirely conventional here.

Re: Pkl, a Programming Language for Configuration

#366
post #351

Earlier quoted context omitted.

Nix is a bunch of things, one of which is a configuration language.

A major difference is that Nix has no type system or schema. Pkl is typed.

The NixOS module system has those and can be used independently of NixOS despite its name.

Re: Pkl, a Programming Language for Configuration

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

You're saying you don't want red squigglies in your IDE when you do your configuration wrong? Why?

Re: Pkl, a Programming Language for Configuration

#368

Earlier quoted context omitted.

For me, that's where all the power of the language comes from. It's like writing your config in Go or Python (which I think is also a great approach) except its designed from the ground up for this use case of config generation.

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?

[deleted]

Re: Pkl, a Programming Language for Configuration

#369
post #245

Earlier quoted context omitted.

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…

I am convinced the Pkl config will grow in complexity until it has a yaml or json config for the configuration program.

Not in my experience.

Re: Pkl, a Programming Language for Configuration

#370
post #280

Earlier quoted context omitted.

> ...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.

Glad I'm not the only one who had this reaction. I just can't bring myself to accept that a problem that could be solved with a slightly better version of JSON or property lists requires this many buzzwords.

Those aren't "buzzwords" though, it's a very specific way to implement programming languages. It's not really meaningful except for the PL implementation nerds.

Especially the Futamura projections. It's almost magic and very few people have even heard of them.

Post reply on HN