Pkl, a Programming Language for Configuration • Hacker News Board

Re: Pkl, a Programming Language for Configuration

#151

Post by ahefner » Sat, Feb 03, 2024, 1:57 PM UTC

randomdata wrote: post #113

bobuk wrote: post #34

it's very brave to release a new configuration language with no Python support today.

Python is able to load Python code at runtime, so one can use Python for configuration. A solution doesn’t need to go looking for problems that are already solved.

...and yet Python people routinely fail to grasp this and end up writing ad-hoc config language interpreters on top of yaml anyway.

Granted the conveniences of Python syntax for code are mostly lost when trying to express tree structured data, and yaml flips that on its head.

(Mumble, grumble, something about s-expressions...)

Re: Pkl, a Programming Language for Configuration

#152

Post by p10jkle » Sat, Feb 03, 2024, 1:57 PM UTC

havaker wrote: post #140

Built-in fetching of http resources and reading files from the filesystem[1] combined with turing-completeness are features that I wasn't expecting from a configuration language. I wonder if the complexity this brings is justified. 1: https://pkl-lang.org/main/current/language-reference/index.h...

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.

Re: Pkl, a Programming Language for Configuration

#153

Post by ughitsaaron » Sat, Feb 03, 2024, 2:00 PM UTC

leonheld wrote: post #131

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.

> but I honestly suspected somebody is trying to make fun of me with some concentrated technobabble Let me tell about a revolutionary device called a Turbo encabulator.

sounds like a perfectly cromulent topic to embiggen our knowledge.

Re: Pkl, a Programming Language for Configuration

#154

Post by p10jkle » Sat, Feb 03, 2024, 2:01 PM UTC

devmor wrote: post #111

reactordev wrote: post #88

Is this a joke? Why? We have so many usable formats already. Every language can do JSON. What problem does this solve? Or is this another Apple solution to a problem that doesn't exist?

I do not find this particularly interesting because the problem has been solved by several projects already, but this is a programmable configuration file. i.e. you can write code statements and it transpiles down to other formats

I'm not sure I'd agree its solved already, yes we have some languages (Dhall or Cue probably lead the pack) but I hugely prefer Pcl's syntax and approach. It's like saying that C solved systems languages, so there's no reason to have Go or Rust

Re: Pkl, a Programming Language for Configuration

#155

Post by bbkane » Sat, Feb 03, 2024, 2:01 PM UTC

IshKebab wrote: post #72

mirekrusin wrote: post #40

So like cue [0] but more primitive, less principled and in java? [0] https://cuelang.org

Looks like it might fix three big issues I had with Cue: 1. The only way to use it is to run their Go CLI app to convert the Cue into JSON and then load that. That sucks. I want native support. Jsonnet does this a lot better ( https://jsonnet.org/ref/bindings.html ), and PKL at least supports 4 languages. Cue only supports Go directly. Not good. 2. Cue has a super fancy type system, but as far as I could figure out t…

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

Re: Pkl, a Programming Language for Configuration

#156

Post by p10jkle » Sat, Feb 03, 2024, 2:03 PM UTC

rcarmo wrote: post #133

snom380 wrote: post #74

Earlier quoted context omitted.

Why assume it's a greenfield project? I would think most open source software that comes out of companies have lived internally for a while before going public?

This. I’m willing to bet I talked to one of the people who use this internally at Apple a few years back when I interviewed there (before they decided to do away with remote hires). They didn’t mention it, but it fits the context.

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

Re: Pkl, a Programming Language for Configuration

#157

Post by cyanydeez » Sat, Feb 03, 2024, 2:03 PM UTC

jgrahamc wrote: post #107

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

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

all I saw was oracle

Re: Pkl, a Programming Language for Configuration

#158

Post by 4ad » Sat, Feb 03, 2024, 2:05 PM UTC

bbkane wrote: post #147

4ad wrote: post #59

Earlier quoted context omitted.

FWIW, we (CUE) are currently working on a LSP for CUE which should improve the IDE experience.

I've been somewhat surprised that CUE bills itself as "tooling friendly" and doesn't yet have a language server- the number one bit of tooling most devs use for a particular language. I'm assuming it's becaus CUE is still unstable? Anyway, if others are interested in CUE's LSP work, I think https://github.com/cue-lang/cue/issues/142 is the issue to subscribe to

Tooling friendly can mean different things to different people. Similarly, different groups of people have different priorities.

It has always been clear that LSP was high priority, but we have many other high priority work that also needs to be done. Most of the work that we do is driven by feedback and demand from the community.

Additionally, we want to do the LSP right instead of quickly hacking something together. That requires more work than one might think.

While CUE has not reached 1.0 yet, people definitely use CUE in production and we work hard not to break any of their code. I can assure you LSP is missing simply because we had other things to tackle first and not because the language is unstable in a colloquial sense.

Re: Pkl, a Programming Language for Configuration

#159

Post by egberts1 » Sat, Feb 03, 2024, 2:05 PM UTC

ughitsaaron wrote: post #153

leonheld wrote: post #131

Earlier quoted context omitted.

> but I honestly suspected somebody is trying to make fun of me with some concentrated technobabble Let me tell about a revolutionary device called a Turbo encabulator.

sounds like a perfectly cromulent topic to embiggen our knowledge.

Perfectumentous!

Re: Pkl, a Programming Language for Configuration

#160

Post by mikepurvis » Sat, Feb 03, 2024, 2:06 PM UTC

havaker wrote: post #140

Built-in fetching of http resources and reading files from the filesystem[1] combined with turing-completeness are features that I wasn't expecting from a configuration language. I wonder if the complexity this brings is justified. 1: https://pkl-lang.org/main/current/language-reference/index.h...

Nix does this too and maintains perfect caching from top to bottom.