281–290 of 598 posts
Systems like pkl and skylark live on their own and isn't well integrated with systems outside it (for example, an object inside a configuration might want to generate a log source definition in the central logstash config, or a new object in the monitoring system).
Built-in fetching of http resources and reading files from the filesystem[1] combined with turing-completeness are features that I wasn't expecting from a configuration language. I wonder if the complexity this brings is justified. 1: https://pkl-lang.org/main/current/language-reference/index.h...
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.
> duration3 = 5.ms // milliseconds
grumpy sounds
so we're reinventing lisp yet again?
I have been looking into alternatives to YAML templating, the Helm abomination, etc. and was utterly surprised how no one ever apparently has thought to create a configuration/templating system that's basically a fancy library on top of Scheme. I truly believe every company is still reinventing the wheel because of a lack of serious foundational knowledge in most engineers, so they are doomed to recreate subpar, shit…
There's Clojure's extensible data notation: https://github.com/edn-format/edn
Earlier quoted context omitted.
That all sounds cool, but is any of that especially useful for a configuration language?
I’m also curious, because Graal is pretty exciting stuff, what this might give over Jsonnet or Cuelang. It’s already a hard enough sell to try to get people to adopt these and they are much older and more robust than Pkl.
I really like Pkl's comparison page, which includes its weak points as well! https://pkl-lang.org/main/current/introduction/comparison.ht...
Pkl’s native binaries are larger than those of other config languages.
It should be as fast and easy to use and reliable as something like esbuild, so I'd suggest they may want to rewrite it in Go like esbuild. I'm not a Go fan at all, but it clearly does some things really well.
Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futamura Projections. We have been working with Apple on this for a while, and I am quite happy that we can finally read the sources! https://github.com/oracle/graal/tree/master/truffle Disclaimer: graalvm dev here. Edit: typo
See also https://pkl-lang.org/index.html (via https://news.ycombinator.com/item?id=39239265 , but we merged that thread hither)
Earlier quoted context omitted.
> Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futamura Projections. What now?
As I understand it: GraalVM is an alternate JDK that can, among other things, do ahead-of-time compilation for Java. Truffle is a framework for building languages, that sits on top of Graal. Futamura Projections are a particularly interesting use case for compile-time partial evaluation. With partial evaluation you have static (known at compile time) arguments to your function, and dynamic (known at runtime) argument…
wtf is Graal? That sounds like a supporting character from Beowulf.
Earlier quoted context omitted.
> Guess the obvious question is why don’t you want types in your config language? The disadvantage of typed configuration languages is they make assumptions about the format of the data. For you a "date" type might mean ISO 8601, but for me it might mean RFC 3339. Config languages that make assumptions are coupling the language and schema validation together. The alternative is to decouple them: offer a flexible conf…
> For you a "date" type might mean ISO 8601, but for me it might mean RFC 3339 A generic date type doesn’t come with any specific string format. ISO 8601 and RFC 3339 are both ways of representing a date as a string. Which has little to do with Date as a type. There’s also perfectly good solutions to those problems. Use a type alias to create a date type backed by a string, with formatting constraints (such as a rege…
Tell that to the TOML authors [1].
It's good Pkl has string validation, but what if I don't want a string? What if I want my own literal datetime syntax, like TOML? The grammar for a configuration language could be made flexible enough to accept most anything as a value. In such a design the "string" type itself could be a regex rule defined by a schema.
Keep in mind datetime literals are just an example, the actual number of potential types is unbound.
Earlier quoted context omitted.
What advantages does Turing-completeness provide for a configuration language?
There are three (maybe more?) ways things can be Turing-incomplete: 1. You are limited to N evaluation/reduction steps. 2. The language doesn't include primitives like recursion or loops. 3. You can have recursion or loops, but the language makes you somehow prove that your program will terminate. I think (1) would be fine, but I don't know any configuration languages that use this approach. (2) is restrictive/annoyi…