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

581–590 of 598 posts

Re: Pkl, a Programming Language for Configuration

#581

Post by H12 »

Too wrote: post #469
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.

We do have a degree of abstraction through terraform modules, but I've found that the same copy-paste problem applies to the terraform that composes those modules together.

This is possibly (if not likely) moreso a result of creating our terraform modules in a suboptimal way due to insufficient expertise than a shortcoming of Terraform itself.

It is also largely a result of having a backlog of scheduled redactors that is longer than I'd care to admit.

Re: Pkl, a Programming Language for Configuration

#582

Post by 4ad »

kkukshtel wrote: post #569
the_duke wrote: post #161

Earlier quoted context omitted.

I really like CUE, but for most use cases I have I would want to embed it in an application, and Go is the only language with support. For it to gain more adoption it really needs a rewrite in a low-level language (C/Rust), so it can be exposed in various languages through an extension/FFI.

This is honestly my only complaint about Cue after having it used it for a few weeks after looking at everything else in the space (KCL, Jsonnet, Dhall, etc.). Cue is incredible imo and the commenter above talking about not being able to define the schema vs. the data is sort of missing the point - Cue makes them the same thing in a way that really understands the whole role of config langauges and IMO is way better…

Thank you for your comment. We're working hard to add support for other languages. I agree that exposing a Go library as a C shared object is non-trivial and rough around the edges. We are committed to polishing these edges.

Re: Pkl, a Programming Language for Configuration

#583

Post by jhardy54 »

bsdpufferfish wrote: post #527
jhardy54 wrote: post #526

Earlier quoted context omitted.

Yeah, it’s really great that compiling C is a straightforward endeavor that doesn’t require any tools, and definitely doesn’t depend on executables that generate or parse configuration files. I’m confident that no C developers have ever spent time on tool setup just to program.

gcc main.c Of course tinkerers made some tools you can tinker with as time went on, but you don’t have to let those interfere with velocity, just like I will not be using configuration languages.

Do you mind linking me to some large C projects that don’t use make/autotools/etc?

Re: Pkl, a Programming Language for Configuration

#584

Post by skinner927 »

hot_gril wrote: post #554
mekster wrote: post #457

Earlier quoted context omitted.

At one time I just gave up on using any config formats and instead went back to the good old simple "use the programming language as the config file too" approach. It's certainly not cross language capable but when your editor knows exactly what's there and what's not with auto completion from the config file, that was a superior experience than caring about cross language issues that may not even be a problem depend…

Yep, I've always got a config.js. But that's a luxury compiled languages won't have.

Ship your config as a .so/.dll ! :P

Re: Pkl, a Programming Language for Configuration

#587

Post by summerlight »

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

It'd be interesting to understand what kind of performance problem Apple had and tried to solve with GraalVM/Truffle. I've seen some instances of heavy configs that generate literally several gigabytes of data, but those were usually not significant bottlenecks since configs are not updated very frequently.

Of course, I know those two frameworks are one of the engineering marble of the age and would understand even if they decided to go without any concrete needs for it.

Re: Pkl, a Programming Language for Configuration

#588

Post by SureshG »

iainmerrick wrote: post #285
SOLAR_FIELDS wrote: post #215

Earlier quoted context omitted.

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.

I'm very wary of anything Java-based, having been burned by Java tooling in the past. I work on a few different Android projects and I have to switch between three different JDK versions depending on which I'm working on. What happened to "write once, run anywhere"?? I really like Pkl's comparison page, which includes its weak points as well! https://pkl-lang.org/main/current/introduction/comparison.ht... Pkl’s nativ…

>"write once, run anywhere"??

You know that the code compiled using future version of java won' work in older versions..rt? I would like to know if any other programming language does that kind of thing.

> t should be as fast and easy to use and

How did you conclude that it's not fast? They are creating native binaries just like Go or any other AOT languages with GCs. Graal native images are as fast or faster than Go. Also it contains a REPL, that's why bigger size. So for CLI tooling as a developer using pkl, you won't see any difference if it's written in java + kotlin or golang.

Post reply on HN