Pkl, a Programming Language for Configuration • Hacker News Board

Re: Pkl, a Programming Language for Configuration

#561

Post by bborud » Mon, Feb 05, 2024, 12:26 PM UTC

Fischgericht wrote: post #413

n42 wrote: post #406

Earlier quoted context omitted.

Yes, the windows registry, the peak of our craft. No need to innovate, this one’s solved, wrap it up and move on Try taking more time to consider the problems you don’t have that others do, instead of writing anything off that doesn’t make sense to you (and simultaneously gatekeeping an entire industry)

Creating complex layers upon layers just to "solve" a very simple problem is not innovation. It's shittification.

It is no different when you are trying to solve a complex problem and complex layers upon layers obfuscate and confound you when you are trying to figure out why some component ends up with configuration values that are nowhere to be found in your input files.

Re: Pkl, a Programming Language for Configuration

#562

Post by mieubrisse » Mon, Feb 05, 2024, 12:29 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?

A big problem we've hit with allowing users to write Typescript (or any other general-purpose programming language) for our product is that it's too powerful.

Observationally, it seems that all that power eventually gets used, and then you end up with config that has complex interfaces, or becomes non-portable because it's doing arbitrary file reads, or is non-deterministic because of an ill-advised call to random or the system clock. The config then becomes something not maintainable by the rest of the team - just the few who know it.

Config languages seem to need to strike an interesting balance between being complex enough to allow for reasonable DRY code (which helps maintainability at the expense of readability), but not so complex that they're not generally-maintainable.

Re: Pkl, a Programming Language for Configuration

#563

Post by HelloNurse » Mon, Feb 05, 2024, 1:37 PM UTC

jmull wrote: post #245

avianlyric wrote: post #209

Earlier quoted context omitted.

Guess the obvious question is why don’t you want types in your config language? Pushing all the validation to parsing state just makes it hard to write valid config, because you only know if the config is valid when you feed it into your program. Having the ability to pull all that validation forward, and into your IDE, means you can be told about invalid config as you’re writing it. To me the idea of only wanting to…

Yeah, generally, you want to validate as early as practical... catching problems sooner is better than later. I think the problem might be separation of concerns... pkl comes in early, and by design is separated from your app and the details thereof. It seems good for validating high-level or external configuration constraints. But suppose you have some constraints based on implementation details of your app. Now you…

Fixing the app implementation details so that the configuration stays "clean", or at least forcibly documenting them so that the configuration can be written correctly, is vastly better than allowing the app to make undocumented surprises with its private validation.

Re: Pkl, a Programming Language for Configuration

#564

Post by mrudolph22 » Mon, Feb 05, 2024, 3:21 PM UTC

hot_gril wrote: post #555

flexagoon wrote: post #506

Earlier quoted context omitted.

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

More people know TS (or JS, close enough) than Pkl, it can be used for more, and it's got better tooling/support. Those are understatements.

TS tooling won’t tell you when your config value violates the constraint “isBetween(0, 100)” or “matches(Regex(…))”. Among other things.

Re: Pkl, a Programming Language for Configuration

#565

Post by renonce » Mon, Feb 05, 2024, 4:39 PM UTC

Developing a whole new language whose reference contents page spans two phone screens, with classes, built-in packages and methods, bindings for various languages and language servers for various IDEs, just to replace yaml? Seriously? Either the configuration is broken, or if the yaml is doomed to be repetitive to be repetitive (to allow flexibility etc), won’t sandboxed JavaScript do the job of outputting a readable yaml?

Re: Pkl, a Programming Language for Configuration

#566

Post by kika » Mon, Feb 05, 2024, 6:31 PM UTC

krick wrote: post #531

Honestly, I don't imagine this being a good idea. The problem it solves is pretty clear, and it's easy to see how one attains the desire to solve that, but is it really that kind of problem which should be solved? It is kinda commonplace that you don't write configuration in the real PL. Maybe it's less obvious, when your working language is Go/Java, since they are compiled, so obviously you have no choice but to kee…

I'm still on the fence (and distracted by Vision Pro). It's a good-ish idea, IMHO. I'd like to see a toolkit for "reading configs" where configs are some universal format (JSON, YAML, TOML, etc) for various languages. So that the app in Ruby can share config with "microservice" in Rust and they can also maintain compatibility with completely different app (but sharing infra resources) in Go. Using one config language that supports hierarchical templates, modules, imports, whatever. Because otherwise everyone starts inventing their own "YAML with functions", "JSON with templates", etc. Pkl seems like that. But I don't like that it's Turing complete. Powerful and dangerous. Configs are inherently declarative.

Re: Pkl, a Programming Language for Configuration

#567

Post by flexagoon » Mon, Feb 05, 2024, 6:38 PM UTC

pard68 wrote: post #532

flexagoon wrote: post #508

Earlier quoted context omitted.

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

I was wrong. I meant Treesitter sucks in vscode

VSCode doesn't support tree-sitter at all, it doesn't "suck", it just doesn't exist

Re: Pkl, a Programming Language for Configuration

#568

Post by hot_gril » Mon, Feb 05, 2024, 9:14 PM UTC

mrudolph22 wrote: post #564

hot_gril wrote: post #555

Earlier quoted context omitted.

More people know TS (or JS, close enough) than Pkl, it can be used for more, and it's got better tooling/support. Those are understatements.

TS tooling won’t tell you when your config value violates the constraint “isBetween(0, 100)” or “matches(Regex(…))”. Among other things.

A config validator, which can be written in TS, would.

Re: Pkl, a Programming Language for Configuration

#569

Post by kkukshtel » Mon, Feb 05, 2024, 10:06 PM UTC

the_duke wrote: post #161

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 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.

This is honestly my only complaint about Cue after having it used it for a few weeks after looking at everything else in the space (KCL, Jsonnet, Dhall, etc.). Cue is incredible imo and the commenter above talking about not being able to define the schema vs. the data is sort of missing the point - Cue makes them the same thing in a way that really understands the whole role of config langauges and IMO is way better for it. When you start to really understand what a config language _should_ do, Cue is the only option, and most attempts to dismiss it seem like hand-waves in order to push some other preference.

However it only being in Go and not implemented with some C ABI is a major downside for adoption, especially when their documentation itself for implementing the core CLI functionality in a go program (to then compile to a DLL for use in non-Go land) is pretty sparse.

Re: Pkl, a Programming Language for Configuration

#570

Post by rockwotj » Mon, Feb 05, 2024, 11:58 PM UTC

mieubrisse wrote: post #562

rockwotj wrote: post #282

Earlier quoted context omitted.

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?

A big problem we've hit with allowing users to write Typescript (or any other general-purpose programming language) for our product is that it's too powerful. Observationally, it seems that all that power eventually gets used, and then you end up with config that has complex interfaces, or becomes non-portable because it's doing arbitrary file reads, or is non-deterministic because of an ill-advised call to random or…

I feel like this is what code review is for. Isn’t this also possible with your application code? How do you prevent that?

As for I/O concerns, run it in CI with deno and ensure there is no I/O