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

271–280 of 598 posts

Re: Pkl, a Programming Language for Configuration

#271

Post by saynay »

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.

Looks like a more robust type system than Jsonnet (but less than Cue), with some amount of flow-control that Cue doesn't seem to support. I am not very familiar with Cue though.

Re: Pkl, a Programming Language for Configuration

#272

Post by mardifoufs »

9dev wrote: post #262
avianlyric wrote: post #163

Earlier quoted context omitted.

Probably because JetBrains only recently added native LSP to IntelliJ[0] etc. Given that writing anything in Java/Kotlin basically requires the use of IntelliJ, it’s not really surprising that a language built on top of Truffle and GraalVM, all Java technologies, would ship with an IntelliJ plugin, _but not_ an LSP. Because such an LSP would have been useless in the primary IDE used by the language developers. So if…

The experience with LSPs is quite underwhelming compared to what a native language plugin in IntelliJ can do. That isn’t to say the approach is bad, but it’s definitely a trade off.

How come? I don't know anything in say, pycharm, that can't be done with a LSP server and plugins. But that's probably because I don't know enough so I'm curious about what limitations an LSP would involve!

Re: Pkl, a Programming Language for Configuration

#274

Post by mardifoufs »

criddell wrote: post #193
OJFord wrote: post #82

Earlier quoted context omitted.

Well I suppose that's what I'm asking, is that the case? I'm not aware of other projects that have a separate plug-in due to LSP shortcomings, so just interested if there is something they're doing that's not possible/won't be in the LSP one.

I think the answer to your question is yes: LSPs can’t do everything that a plugin can do. https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-d...

That sounds like a limitation on Jetbrains part, no? Or is it due to LSPs themselves?

Re: Pkl, a Programming Language for Configuration

#275

Post by 8lall0 »

IshKebab wrote: post #252
bbkane wrote: post #155

Earlier quoted context omitted.

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…

Do you have 5 minutes to talk about TOML?

Re: Pkl, a Programming Language for Configuration

#277

Post by p10jkle »

3np wrote: post #231
p10jkle wrote: post #156

Earlier quoted context omitted.

Yes, I was using it when I joined Apple in mid 2020

Don't leave is hanging, how was your experience? (Pkl, not Apple :p)

I absolutely loved it and I’ve been extremely impatient to see its release. I used it to generate k8s manifests, Terraform, all infra config files. Very flexible and fun to use

Re: Pkl, a Programming Language for Configuration

#278

Post by lucianbr »

jmull wrote: post #245
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…

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.

Re: Pkl, a Programming Language for Configuration

#280

Post by EPWN3D »

krajzeg wrote: post #109
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

> ...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.
Post reply on HN