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 keep configuration in an interpreted format. But you also don't do that in Python/PHP/Javascript. You could just write configuration using full power of Python, right? But even when you do keep some configuration as Python code (because it's only developers who are tweaking these constants anyway, etc.), you usually prefer a plain dict for that, not a bunch of dynamically generated classes with multi-level inheritance.
So, ok, maybe it makes sense when you have to deal with a over-engineered fucked up third party tool like k8s, which you have to configure in YAML, and you could just make it less verbose and have some schema? Well, I don't know, maybe. But the point holds. The good thing about YAML/JSON/etc is that they are very declarative (even when they are used a as imperative DSL syntax, as in GitHub Actions or k8s). If you see that port = 6001, it's 6001, that's it. Your entire DB configuration is right there, in front of you.
The biggest selling point of PKL seems to be that "sidecars" example. And, I mean, sure, it's precisely the problem we intended to solve. But it also shows that you (oh, not you, but your co-worker, of course) could write pretty much anything. It doesn't look like a configuration anymore to me. It's exactly keeping your "configuration" in the source-code of your app, in a real PL, using dynamically generated classes in a cycle and whatever. The thing, we don't usually do for some reason.
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.
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 keep configuration in an interpreted format. But you also don't do that in Python/PHP/Javascript. You could just write configuration using full power of Python, right? But even when you do keep some configuration as Python code (because it's only developers who are tweaking these constants anyway, etc.), you usually prefer a plain dict for that, not a bunch of dynamically generated classes with multi-level inheritance.
So, ok, maybe it makes sense when you have to deal with a over-engineered fucked up third party tool like k8s, which you have to configure in YAML, and you could just make it less verbose and have some schema? Well, I don't know, maybe. But the point holds. The good thing about YAML/JSON/etc is that they are very declarative (even when they are used a as imperative DSL syntax, as in GitHub Actions or k8s). If you see that port = 6001, it's 6001, that's it. Your entire DB configuration is right there, in front of you.
The biggest selling point of PKL seems to be that "sidecars" example. And, I mean, sure, it's precisely the problem we intended to solve. But it also shows that you (oh, not you, but your co-worker, of course) could write pretty much anything. It doesn't look like a configuration anymore to me. It's exactly keeping your "configuration" in the source-code of your app, in a real PL, using dynamically generated classes in a cycle and whatever. The thing, we don't usually do for some reason.