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

461–470 of 598 posts

Re: Pkl, a Programming Language for Configuration

#461

Post by bioballer »

taywrobel wrote: post #407

Wow, I was at Apple back in the 2018 timeframe when Peter was first building this. He was hoping to make it open sourced even back then, 6ish years ago. Great to see that it finally made it. I really wish Apple would learn to play nicer with the OSS community. I have yet to see them deciding to open-source something backfire on them monetarily or reputationally, and I've seen the act of them abruptly close-sourcing t…

Hey, I recognize this name :D

Yeah, it's been a long time coming, and it feels great to finally get this out in open source.

FDB is open source too, BTW: https://github.com/apple/foundationdb

Re: Pkl, a Programming Language for Configuration

#462

Post by beanjuiceII »

ithkuil wrote: post #175
grashalm wrote: post #79

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

Futamura

That's iron chef futamura to you

Re: Pkl, a Programming Language for Configuration

#463

Post by Too »

__MatrixMan__ wrote: post #448
rockwotj wrote: post #282

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?

My impression of typescript is that if you do: a = 1; and elsewhere: a = 2; The ultimate value of 'a' will depend on the order in which those statements are executed, right? A configuration language should surface that as an error and tell you where all of the conflicting references are.

Typescript does have const variables. But you can still often mutate the instances and there are many other reasons why a configuration language should be strictly free from side effects allowed in imperative languages.

Re: Pkl, a Programming Language for Configuration

#464

Post by bioballer »

SOLAR_FIELDS wrote: post #215
iainmerrick wrote: post #202

Earlier quoted context omitted.

That all sounds cool, but is any of that especially useful for a configuration language?

I’m also curious, because Graal is pretty exciting stuff, what this might give over Jsonnet or Cuelang. It’s already a hard enough sell to try to get people to adopt these and they are much older and more robust than Pkl.

Pkl is newly open sourced, but it not new. It's been used for years at Apple, and has been battle tested internally.

I'd actually say that our tooling in some ways is more mature. For example, I think our IDE experience (at least in JetBrains editors) is the best out there.

Re: Pkl, a Programming Language for Configuration

#465

Post by Too »

hgs3 wrote: post #263
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…

> Guess the obvious question is why don’t you want types in your config language? The disadvantage of typed configuration languages is they make assumptions about the format of the data. For you a "date" type might mean ISO 8601, but for me it might mean RFC 3339. Config languages that make assumptions are coupling the language and schema validation together. The alternative is to decouple them: offer a flexible conf…

Even more reason to standardize the format used in configurations and to validate it early, rather than at runtime.

Re: Pkl, a Programming Language for Configuration

#466

Post by Too »

maximus-decimus wrote: post #260
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…

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.

Helm is not a proper configuration language. It just does string replace. Unbelievable that people actually use it.

A config language that does have the type information can give proper errors. Try for example terraform.

Re: Pkl, a Programming Language for Configuration

#467

Post by mixmastamyk »

Silphendio wrote: post #443
mixmastamyk wrote: post #421

Earlier quoted context omitted.

Schemas are often better than syntax typing. In other words the program decides what the type is, not the file.

If the schema allows union types, I don't want to deal with unquoted strings.

You don’t deal with syntax period. Union types are not desirable with configuration with the exception of |null perhaps, which should receive a default.

Re: Pkl, a Programming Language for Configuration

#468

Post by __MatrixMan__ »

sanderjd wrote: post #361
mikepurvis wrote: post #355

Earlier quoted context omitted.

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.

Better to learn a tiny corner of nix (which you may later apply to the rest of it, or not) than to learn a language with a narrower use case.

But one who embraces nix fully is one who is willing to commit a lot of time to turning their back on convention. Returning to 90% of the conventions that they worked so hard to leave behind probably won't excite them.

So it's not silly, it's just that the person to do it is culturally unlikely.

Re: Pkl, a Programming Language for Configuration

#469

Post by Too »

H12 wrote: post #318

I'm having a little trouble understanding the problem(s) Pkl is trying to solve. After reading the title, my assumption was that Pkl was yet another newer, better configuration language (a la TOML), but now that I've read the article, it sounds like it's more a language for _generating_ config. Unless I'm mistaken, it sounds like an abstraction on top of your config files meant to help you build & re-use configuratio…

Actually terraform is supposed to address that exact problem itself.

Instead of copy-paste of json files or aws resources, you can write a terraform module to generate it.

If you need to copy paste a large chunk of terraform module it is time to schedule refactoring.

Re: Pkl, a Programming Language for Configuration

#470

Post by matheusmoreira »

pdpi wrote: post #174
jgrahamc wrote: post #107

Earlier quoted context omitted.

> Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futamura Projections. What now?

As I understand it: GraalVM is an alternate JDK that can, among other things, do ahead-of-time compilation for Java. Truffle is a framework for building languages, that sits on top of Graal. Futamura Projections are a particularly interesting use case for compile-time partial evaluation. With partial evaluation you have static (known at compile time) arguments to your function, and dynamic (known at runtime) argument…

> With partial evaluation you have static (known at compile time) arguments to your function, and dynamic (known at runtime) arguments.

That's pretty clever... How is this implemented in actual code though? I can't even begin to imagine how that magic machinery works.

Post reply on HN