Pkl, a Programming Language for Configuration • Hacker News Board

Re: Pkl, a Programming Language for Configuration

#501

Post by konart » Sun, Feb 04, 2024, 2:12 PM UTC

IshKebab wrote: post #252

bbkane wrote: post #155

Earlier quoted context omitted.

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

Yeah I actually haven't found a great answer yet. Here's everything I've tried and why it sucks: * JSON. No comments. Deal-breaker * JSONC. No unique file extension so its difficult to distinguish from JSON. Poor library support due to library authors drinking the "comments are bad" koolaid. * JSON5. This would be an excellent option IMO except that library and IDE support is not great. * JSON6. This just complicates…

Have you seen https://kdl.dev/ ?

Re: Pkl, a Programming Language for Configuration

#502

Post by zamubafoo » Sun, Feb 04, 2024, 2:26 PM UTC

Until Cue/Pkl/whatever the current FotM has FFI that can be realistically utilized from most other languages (ie. not require custom bindings), it won't get real adoption.

Without wide adoption, it's at best an interesting research project. A really cool project I want to work with, but not something I can reasonably bring up.

Re: Pkl, a Programming Language for Configuration

#503

Post by jeremywerner » Sun, Feb 04, 2024, 2:41 PM UTC

Congrats Peter!

Re: Pkl, a Programming Language for Configuration

#504

Post by Bost » Sun, Feb 04, 2024, 2:44 PM UTC

Fischgericht wrote: post #401

25 years ago pretty much every program had a GUI to do the configuration. With help texts. On Windows, programs then either saved stuff into an ini file or the windows registry, both you could also edit manually. Today we have a programming language coming as a 87 MB binary to create config files. And to run that programming language you need to manually crate a ... config file. So what we are missing now is a 500GB…

> So what we are missing now is a 500GB framework that can write the config file for the programming language that is writing a config file for the actual program I wish to use.

That exists since 1960. It's called LISP. The e.g. https://guix.gnu.org/ uses with great success, the Guile Scheme dialect of LISP, to be precise. And FYI the "framework" is:

  $ ls --human-readable --size $(readlink $(which guile))
  16K /gnu/store/1gd9nsy4cps8fnrd1avkc9l01l7ywiai-guile-3.0.9/bin/guile

Yes, only sixteen kilos, not gigas.

Re: Pkl, a Programming Language for Configuration

#505

Post by flexagoon » Sun, Feb 04, 2024, 2:47 PM UTC

Fischgericht wrote: post #411

afavour wrote: post #405

Earlier quoted context omitted.

That strikes me as a very uncurious perspective. There’s absolutely nothing that could be improved about configuration files? An 87MB binary feels like a very arbitrary measure of worthiness.

ONE actual standard that everyone uses would be fine. For non-tree (nested) configurations, an ini file would do. It's a standard that worked well in 1990, and still does today. For nested data, it doesn't matter to me if it's JSON, YAML, TOML or whatever. Just agree on ONE format. TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due…

> They deliberately (!) broke compatibility to the INI format

There is no "ini format" though? INI is a weak set of conventions that different programs parse in a completely different way, it's the opposite of standardization.

Re: Pkl, a Programming Language for Configuration

#506

Post by flexagoon » Sun, Feb 04, 2024, 2:53 PM UTC

rockwotj wrote: post #282

p10jkle wrote: post #152

Earlier quoted context omitted.

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.

Ah just give me typescript, I do not need to learn a new thing for configuration languages and at the end of the day the output is compatible with JSON. Typescript has all the stuff I would want: types, first class json support, an ecosystem of libraries (if you want it, I would probably not for config generation). And the tooling is amazing. Does pkl have LSP, syntax highlighting in every editor, debugger or repl?

> Ah just give me typescript, I do not need to learn a new thing for configuration languages

People who don't know Typescript will still have to learn a new thing in that case, so there isn't really any reason to pick TS over any other existing language

> syntax highlighting in every editor

There is a tree-sitter parser for pkl, so it'll work anywhere where tree-sitter works. And for VSCode and JetBrains stuff, they have official extensions.

Re: Pkl, a Programming Language for Configuration

#507

Post by flexagoon » Sun, Feb 04, 2024, 2:54 PM UTC

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…

Because the current extensions only provide syntax highlighting. The Neovim one uses tree-sitter which is built into NVim.

Re: Pkl, a Programming Language for Configuration

#508

Post by flexagoon » Sun, Feb 04, 2024, 2:55 PM UTC

pard68 wrote: post #98

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…

LSPs in vscode suck

Can you elaborate please? VSCode is literally the reason why LSP even exists

Re: Pkl, a Programming Language for Configuration

#509

Post by pradn » Sun, Feb 04, 2024, 3:51 PM UTC

Fischgericht wrote: post #401

25 years ago pretty much every program had a GUI to do the configuration. With help texts. On Windows, programs then either saved stuff into an ini file or the windows registry, both you could also edit manually. Today we have a programming language coming as a 87 MB binary to create config files. And to run that programming language you need to manually crate a ... config file. So what we are missing now is a 500GB…

The general shift to infrastructure-as-code is tied to a number of new trends and requirements:

1) Code review (config code can be reviewed by humans)

2) Automated pre-submit checks (config code can passed through automated pre-submit checks - such as preventing huge changes, or giving you a nice diff to look at

3) Auditability / history-tracking (you can look at the history of a config file to see who, when, why changes were made - this may even be necessary for compliance reasons)

4) De-duplication (you can extract common components into templates/functions - this supports variation across envs/regions/customers and repetition across tasks/machines/DBs)

All of these features help build large-scale systems in modern corporate environments.

Re: Pkl, a Programming Language for Configuration

#510

Post by __MatrixMan__ » Sun, Feb 04, 2024, 4:04 PM UTC

sanderjd wrote: post #495

__MatrixMan__ wrote: post #468

Earlier quoted context omitted.

Better to learn a tiny corner of nix (which you may later apply to the rest of it, or not) than to learn a language with a narrower use case. But one who embraces nix fully is one who is willing to commit a lot of time to turning their back on convention. Returning to 90% of the conventions that they worked so hard to leave behind probably won't excite them. So it's not silly, it's just that the person to do it is cu…

> Better to learn a tiny corner of nix (which you may later apply to the rest of it, or not) than to learn a language with a narrower use case. "Better" in what way? Like, maybe I agree in some sort of philosophical sense, of how it's better to learn and expand one's awareness of what exists and is possible in the world. That is, better for students , similarly to how I'd say it is better for students to learn lisp a…

If you're:

> a professional figuring out how to set up or refactor the config structure within the non-Nix paradigm of the vast majority of organizations

Then I don't think nix-as-config-only is a good move. But if you're a professional figuring out how to set up or refactor the config structure of some organization, AND for some reason you've already decided that you're going to introduce a language that nobody in the organization uses, then would I say that nix is a good choice. This is because there are probably other people in that organization that would find nix useful if they were already over the syntax adjustment phase.

If a multitool's screwdriver is just as good as a normal screwdriver (granted they're usually not), why not prefer the multitool?

Generally I'd just suggest using whatever languages are already around, config-focused or otherwise. For instance we have a lot of python in our stack so I've found a library called mergedict that gets us close enough to the composability of nix modules without adding a new language.