Live data from Hacker News

Pkl, a Programming Language for Configuration

pkl-lang.org

161–170 of 598 posts

Re: Pkl, a Programming Language for Configuration

#161
post #59

Earlier quoted context omitted.

Looks like it has better IDE integration. Still, I am going to stick with cue because of what you mentioned and also because it is a community project. Apple has very few actively maintained open source projects and sometimes such projects are difficult to contribute to or have wavering support for the open source side. It is great having corporate backing behind something like swift that needs a massive amount of wo…

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

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.

Re: Pkl, a Programming Language for Configuration

#162
post #59

Earlier quoted context omitted.

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

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.

Re: Pkl, a Programming Language for Configuration

#163
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…

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 you wanna blame anyone, blame JetBrains for deliberately making hard to use LSPs with their IDE. Presumably to build a moat around their plugin ecosystem.

[0] https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-d...

Re: Pkl, a Programming Language for Configuration

#164
Having read through the the docs a little, my gut reaction is that they might be a little too much in love with the idea of having created a language that can serve both as schema definition and as minimal values carrier. It smells of unexpected failure modes through overuse [1].

But perhaps this is exactly the core feature: everybody who adds pkl to their software implicitly signs up for participation in whatever configuration monstrosity the downstream stack will end up having. Based on the assumption that that it will be a monstrosity anyways, and that a uniform system would be less bad than an unstructured mess.

Next stage of concerns: if it's a heterogeneous stack that shares one configuration graph, the runtime implementation that is linked into parts of the stack can't ever be allowed to evolve. Ouch. And then there's runtime performance, I wonder if that could eventually become a factor, e.g. if short-lived go processes are involved?

It all seems surprisingly ambitious, very far from the "why not json-with-comments" that was my first reaction (shared with many I assume)

[1] digression: e.g. it reminds me of how in the dark days of peak XML java, a lot of typechecking was effectively thrown overboard because for some unfathomable reason everybody agreed that it would be nice to rearrange objects without a helpful compiler in the room

Re: Pkl, a Programming Language for Configuration

#165
post #32

JSONSchema covers a lot of various schema needs and YAML is something a lot of developers are comfortable with. I know both of those technologies are not popular here in HN but YAML type-checked and editor-autocomplete-enabled using JSONSchema is a solid choice for configurations in my opinion.

Every time I see YAML used for any configuration I know I’m in a frustrating time. It’s particularly bad for build systems where there the feedback time can be so slow.

I agree it doesn't scale well as there are no loops/functions, but there's a lot of good tooling around YAML that other config languages lack:

- mature libs for most languages

- VScode plugin + Jsonschema for auto completion / schema checking

- yamllint to detect the languages footguns

- yq to query, update in place, and format while preserving comments and sorting keys from the CLI

Re: Pkl, a Programming Language for Configuration

#166
post #141

Interestingly, this is exactly the reason the Lua langue was conceived more than 30 years ago.

Are you sure about that? Pkl generates configuration from code. Lua was developed for a couple projects at Petrobras that were used for data entry and data flow. Maybe I don't understand the use-case for Pkl properly.

Re: Pkl, a Programming Language for Configuration

#167

so we're reinventing lisp yet again?

I have been looking into alternatives to YAML templating, the Helm abomination, etc. and was utterly surprised how no one ever apparently has thought to create a configuration/templating system that's basically a fancy library on top of Scheme.

I truly believe every company is still reinventing the wheel because of a lack of serious foundational knowledge in most engineers, so they are doomed to recreate subpar, shitty alternatives.

Re: Pkl, a Programming Language for Configuration

#168

Earlier quoted context omitted.

WebKit? FoundationDB?

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

Yes.

Entire timeline of JavaScript engines.

https://egbert.net/blog/articles/javascript-jit-engines-time...

Re: Pkl, a Programming Language for Configuration

#169

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…

> [CUE] doesn't even have functions.

Note that CUE has comprehensions, which are morally (but not syntactically) functions (actually closures). They are a way to transform values (which can be types) into other values.

We are also adding real function types to CUE. At least in the beginning these functions will be written in other languages than CUE itself, however.

While we are very principled when it comes to language design, we are also very responsive to finding solutions to user's problems, and we welcome any sort of feedback, especially if it's backed by specific use cases and experiences.

As mentioned in another comment, support for languages other than Go is coming.

Re: Pkl, a Programming Language for Configuration

#170

Earlier quoted context omitted.

sounds like a perfectly cromulent topic to embiggen our knowledge.

Perfectumentous!

An author named David Duncan wrote a series of books, called A Man of His Word (and A Handful of Men)[0]. Great books.

One of the races in the books was the Anthropophagi (basically modeled on New Guinea headhunters). They talked like that.

[0] https://en.wikipedia.org/wiki/Dave_Duncan_(writer)

Post reply on HN