Live data from Hacker News

Pkl, a Programming Language for Configuration

pkl-lang.org

291–300 of 598 posts

Re: Pkl, a Programming Language for Configuration

#291

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 tim…

Never used Bazel in my life, so while I can appreciate your passion, I guess I don't share your perspective. Generally the pattern I've seen has been providing a skylark interface to allow folks to define rules or configurations, which are then consumed through by whatever service via starlark-rust or similar implementations.

Re: Pkl, a Programming Language for Configuration

#292
post #144
post #132

sadly the Go implementation is bloated as hell: https://github.com/apple/pkl-go/blob/main/go.sum no thank you.

You should rather look at go.mod file, and it doesn't look bloated at all. They could maybe drop cobra and use something with less dependencies, they use pflag package already so maybse use only that, but uhh I've seen much, much worse worse, as a daily Go user I'd say it's fine

> You should rather look at go.mod file

no. the whole point of go.sum is to see everything. you could have a go.mod with a single item, but if that item is a giant module with hundreds of third party imports (as in this case), its quite misleading.

> I've seen much, much worse worse, as a daily Go user I'd say it's fine

uh where? I am a daily Go user, both professional and personal. and this is one of the most bloated modules I have ever seen.

Re: Pkl, a Programming Language for Configuration

#293
post #162

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.

Making CUE available as a library for other languages is one of our top priorities. Sadly, I can't provide an ETA at this time, all I can say is that I am personally working on this. Getting feedback from the community about what other languages they'd want supported first would be of massive help, however.

.net would benefit from it.

Re: Pkl, a Programming Language for Configuration

#294

Earlier quoted context omitted.

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

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…

holy graals

Re: Pkl, a Programming Language for Configuration

#295

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.

What has most impressed me about GraalVM and Truffle is their capability of deep-optimizing high-level code like Python and Ruby.

I once saw a demo where someone took a simple operation in Ruby using inefficient-but-elegant syntax (including creating and sorting an array, where a simple loop would have been the appropriate approach in C). He compiled that using TruffleRuby and the entire array construction and sorting was completely optimized out of the generated bytecode.

Re: Pkl, a Programming Language for Configuration

#297
post #99

Earlier quoted context omitted.

I wish people named more tech products after popular media instead of common words. Would make it equally hard to web search, but at least it would be funny for non-techies to listen to

You'll really like the Quantum Resistant key exchange algorithm - Kyber. A related project is Cryptographic Suite for Algebraic Lattices or CRYSTALS. Sadly they renamed Kyber to MLKEM.

There is also Dilithium:

https://pq-crystals.org/

Re: Pkl, a Programming Language for Configuration

#299

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

I think everyone appreciates links to similar projects for comparison, but a more in-depth comment would probably come across better - the "less principled and more primitive" sounds like a thoughtless off the cuff ad hominem dismissal.

Consider that some engineers poured a lot of heart into what they were building, and are probably excited to finally share it with the world.

I am not saying you have to love it, but just brutally putting it down with no justification seems really rough. Snark is easy.

Re: Pkl, a Programming Language for Configuration

#300
post #253

Earlier quoted context omitted.

One argument I might put on the cons side of AOT type validation for configs is that there will always be some invalid inputs that can't be statically checked (e.g. port number already taken), and not failing simple type errors before runtime helps keeping in mind and view whatever feedback channel exists for the runtime failure. I wouldn't consider that a winning argument, but it's not entirely without merit.

duplicate port number can be checked in the type system if you’re using racket, at least

Duplicate port number in the config might be checked ahead of time, but port number already taken by something unrelated in the environment deployed to can't. I'm sure that the scope of pkl isn't intended to setting up clean slate containers and nothing else, ever.
Post reply on HN