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

191–200 of 598 posts

Re: Pkl, a Programming Language for Configuration

#191

Post by chefandy »

4ad wrote: post #162
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.

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.

Thanks for working on it. Useful stuff.

Re: Pkl, a Programming Language for Configuration

#192

Post by giancarlostoro »

verticalscaler wrote: post #125
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?

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.

Re: Pkl, a Programming Language for Configuration

#193

Post by criddell »

OJFord wrote: post #82
coldtea wrote: post #78

Earlier quoted context omitted.

> I just don't understand why you'd make that decision on a greenfield project today, especially if LSP support is planned at all? How about if the LSP doesn't cut it for the kind of they IDE support they want to offer?

Well I suppose that's what I'm asking, is that the case? I'm not aware of other projects that have a separate plug-in due to LSP shortcomings, so just interested if there is something they're doing that's not possible/won't be in the LSP one.

I think the answer to your question is yes: LSPs can’t do everything that a plugin can do.

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

Re: Pkl, a Programming Language for Configuration

#195

Post by lars_francke »

4ad wrote: post #162
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.

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.

Because you asked for this feedback: Rust

Re: Pkl, a Programming Language for Configuration

#196

Post by gugagore »

The first thing the page shows is generating configurations in existing formats like YAML. For most of my use cases, there is tooling that does some updates of the configuration (e.g. bumping dependencies), so I'd really need bidirectional support to convert the updates back into Pkl.

Re: Pkl, a Programming Language for Configuration

#197

Post by ajross »

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…

That's my feeling too. Tools like this are trying to squeeze into the space between "straightforward configuration easily maintained in static files" and "complicated state management better served by real code in a real programming language". And that's a real hole for some applications, but it's a small hole.

Basically forcing everyone to learn new tooling (Pkl here, but lots of json/yaml middleware nonsense fits the bill too) just to deal with what really isn't that big of a problem seems like a bad trade.

Re: Pkl, a Programming Language for Configuration

#198

Post by giancarlostoro »

snom380 wrote: post #74
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…

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?

Additionally I cant think of other such projects from Apple. They tend to build things that get used extensively till the end of their life is consumed.

I wish Apple would continue to open source much more. Especially old software much like Microsoft does. I would kind of enjoy a Linux Distro that can natively run old Apple software and tools.

Re: Pkl, a Programming Language for Configuration

#199

Post by leapis »

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…

I mostly agree with this, but I've been a big fan of having primitive types in config. Most of the time if I have something I want to configure, it's either one of the following (or a map/list-based structure consisting of):

- scalar value

- feature toggle

- URI/enum option/human readable display text

Having float/long/boolean is trivial to validate in the config language itself, and if they're useful and simple enough isn't it nice to be able to validate your config as early as possible?

Post reply on HN