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

201–210 of 598 posts

Re: Pkl, a Programming Language for Configuration

#201

Post by lolinder »

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

Meanwhile, from what I can tell Pkl has a single Truffle implementation that currently supports 4 languages, it has a syntax that is more familiar to me as a non-Python dev, it has static typing, and it has a dedicated plugin in most IDEs (whereas Starlark just says to install the Bazel plugin). Maybe Starlark is more appealing to people writing Python or already using Bazel, but for the rest of us there's no contest right now.

Re: Pkl, a Programming Language for Configuration

#202

Post by iainmerrick »

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…

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

Re: Pkl, a Programming Language for Configuration

#203

Post by cduzz »

Is this a reasonable tool to manage problems like:

I've got a stream of json in one schema; I want to make ETL for this to write it out to elasticsearch, S3 (in a specific different schema) and postgres targets, using a mixture of "bespoke python", vector, and logstash.

Should I use this or should I roll my own goo using ERB or mustache or similar?

Or should I quit and go work some place that's using gRPC?

Re: Pkl, a Programming Language for Configuration

#204

Post by ricardobeat »

acuozzo wrote: post #185
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…

Reduce it further: strings and maps. Arrays can be represented as a map.

Strings can be represented as arrays too. Doesnt make a good argument for removing them.

Re: Pkl, a Programming Language for Configuration

#205

Post by zdw »

viraptor wrote: post #70
astrange wrote: post #61

Earlier quoted context omitted.

WebKit? FoundationDB?

I didn't include webkit since it's a forked KHTML, which wasn't theirs.

I didn't include Linux because it's just a Unix reimplementation, not theirs.

or:

I didn't include Firefox because it's just an NCSA Mosaic fork, not theirs.

The point being, whoever does most of the work and maintenance owns something, not who came up with some early predecessor.

Re: Pkl, a Programming Language for Configuration

#206

Post by maxfurman »

giancarlostoro wrote: post #192
verticalscaler wrote: post #125

Earlier quoted context omitted.

On tonights episode of Futurama bender and the gang explore the temple of Pkl on planet VM where truffles are considered the holy graals and barely run away in time from - The Compilations - an ancient secretive order of silver voiced kong-fu monks tasked with protecting the shrine from alien invaders as has been foretold in prophecies - and strangely reminiscent of 20th century Earth doo-wop group The Drifters. Cue…

I definitely did a double take to make sure they didn’t write Futurama.

I absolutely thought they wrote Futurama until I saw this comment

Re: Pkl, a Programming Language for Configuration

#207

Post by avisser »

Xiol32 wrote: post #188
krajzeg wrote: post #109

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.

Really glad it wasn't just me. Genuinely thought someone was trying to make a joke.

Same - it doesn't help that I read Futamura as Futurama the first 3 times.

Re: Pkl, a Programming Language for Configuration

#209

Post by avianlyric »

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 validate config at the last possible moment, is a bit like advocating for only using simple text editors, and replying purely on build failures for feedback. Sure you can do it, but why would subject yourself to that?

Pkl is interesting because it makes it possible to describe not just the types, but also valid configs. Effectively allowing you to ship your applications config parsing and validation into Pkl, so your code can just expect valid config. Then Pkl can expose all that parsing and validation logic into your IDE, so you get pointers as you type. Just like you do in any modern IDE for any modern language.

Re: Pkl, a Programming Language for Configuration

#210

Post by bradly »

OJFord wrote: post #66

> We offer plugins and extensions for IntelliJ, Visual Studio Code and Neovim, with Language Server Protocol support coming soon. Why? Why would they not have just done the language server first (or only)? All of those have built-in support for it, so separate implementations wouldn't have been necessary; that's the point . I just don't understand why you'd make that decision on a greenfield project today, especially…

Pkl has been widely used at Apple for years. It is not a greenfield project.
Post reply on HN