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?

Agreed. If we're getting the point where you're saying "it's like writing your configuration in [insert Domain Specific Language Here]" then I'd prefer to simply use that language. I understand the point Pkl is making in that "configuration won't work across DSLs so here's one language for all of them" but I don't know that that's enough motivation for people to adopt it.

However, I haven't built anything cool like this so what do I know. I'm just procrastinating on the my personal project and browsing hacker news.

At one time I just gave up on using any config formats and instead went back to the good old simple "use the programming language as the config file too" approach.

It's certainly not cross language capable but when your editor knows exactly what's there and what's not with auto completion from the config file, that was a superior experience than caring about cross language issues that may not even be a problem depending on the project.

If you must, you can easily make an identical copy of the config in the build process to convert it to another language.

Yep, I've always got a config.js. But that's a luxury compiled languages won't have.

Ship your config as a .so/.dll ! :P

This might actually be done pretty often.

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.

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

Yep, application code can have the same problem! The difference is that application code lives "inside the abstraction" of the program, and is viewed and edited by a much smaller set of developers.

Configuration, by contrast, sits at the seam between two systems. It's the top-level parameterization of the abstraction, and behaves more like an API. E.g. imagine if the only way to configure Kubernetes or Docker were in language-specitic bindings - there was no such thing as a YAML lingua franca.

My impression of typescript is that if you do:

a = 1;

and elsewhere:

a = 2;

The ultimate value of 'a' will depend on the order in which those statements are executed, right?

A configuration language should surface that as an error and tell you where all of the conflicting references are.

Typescript does have const variables. But you can still often mutate the instances and there are many other reasons why a configuration language should be strictly free from side effects allowed in imperative languages.

If your tsconfig settings are strict enough this is a type error :)

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

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.

In theory, yes. But I doubt that we’ll see a TS IDE plugin that underlines violated constraints with red squiggles anytime soon. :-)

There are IDEs that auto-run unit tests and highlight exceptions thrown in the main or test code, which wouldn't be far off.

Agreed, runtime checks can be implemented in typescript - that’s the beauty of it