from-nibly
6 days ago
I am very excited to watch this new space unfold. Its a huge hole in platform engineering. We need a lot of config but there often arent robust enough config languages so people end up resorting to using Turing complete languages and thats just lighting a fuse for your future self.
Im really excited about cuelang what is everyone else keeping an eye on?
layer8
6 days ago
From what I observe we haven’t found a good model for configuration languages yet, in the space between pure data on the one end and Turing-complete languages on the other. In particular if the languages are also aimed at non-developers, like traditional, mostly key-value configuration files are (INI files, many Unix configuration file formats).
As is often noted, the goal of avoiding Turing-completeness is a red herring, because restricting a language to (say) primitive-recursive functions still easily allows programs that don’t halt in any remotely practical time, and effectively still allows to emulate Turing machines up to some large if finite upper bound of execution steps.
We want some expressiveness and some ability for functional abstraction in our configuration languages (variable substitutions, simple macros, and the like), but we also don’t want them to become full-blown programming languages allowing arbitrarily complex programs. However, it’s not clear that there really is a sensible and principled middle ground.
andrewflnr
6 days ago
Does total functional programming not do it for you as a middle ground? In particular look at Dhall and its theoretical properties, but there are more possibilities where that came from. There are a lot of typed lambda calculi with various normalizing properties, which I believe can be read as nice analyzability, halting but still somewhat expressive.
layer8
5 days ago
Total functional programming corresponds to what I wrote with regard to primitive-recursive functions, so no.
atombender
6 days ago
I think KCL [1] looks really promising.
It's a statically typed data language that takes inspiration from many things, including Python/Starlark.
Unlike Jsonnet etc., it encourages separating pure data from transformation. You can define a type-safe schema for your data, and then write code that "renders" this into the final schema.
It comes with schemas for things like Kubernetes, and it's been adopted by the CNCF. I would be really happy if this becomes the de facto way to write Kubernetes manifests.
mananaysiempre
6 days ago
Dhall[1] also usually gets mentioned in the same sentence as CUE.
As for Nickel, I have mixed feelings about it of the same kind as about ES6 classes and perhaps modules—we’re taking a simple language (an extremely simple one, in the case of Nix) and baking into it some stuff that the original had as a completely satisfactory library, in the name of discoverability resp. uniformity. Seems a bit sad and unnecessary to be honest. (The problem of Nixpkgs and NixOS, IMO, is not Nix the language, which is fine for the most part, but the fact that they’re a single giant monorepo with comparatively very little documentation even for the parts that basically serve as the Nix standard library.) Looks like my design sensibilities just align much better with PhD-student Eelco than with Tweag-engineer Eelco.
kevindamm
6 days ago
Dhall does seem to have more integrations but I really like the amount of thought that has gone into Cue's types and operational semantics.
mananaysiempre
6 days ago
I agree. If only they wrote down the typechecking/evaluation semantics, even if it’s in the traditional form of a page’s worth of cryptic deduction rules.
kevindamm
6 days ago
I think [1] is a good summary of the types and [2] to be a good explanation of their philosophy, but I had some experience with lattice theory and typed feature structure grammars which helped a lot. There are a couple of papers cited in [2] that would help a lot in providing background.
Not quite a one-pager! Maybe it would make a good blog post...
[1]: https://cuelang.org/docs/concept/the-logic-of-cue/
[2]: https://github.com/cue-lang/cue/blob/master/doc/ref/impl.md
Smaug123
6 days ago
Is there a particular feature in Nickel you object to? When I think of Nickel I imagine the merging of contracts (and not much else really - that seems like its big flagship feature to me), which seems to me like a pretty minimal necessary feature to model Nixpkgs idioms; is that one of the features you don't like?
andrewflnr
6 days ago
I'm excited too. I took a half-hearted stab at the problem when I was 16 or something and seeing a giant computed-JSON-shaped hole in the landscape, so it's been nice to see my intuition confirmed by the arrival of JSonnet, Cue, Dhall, Nickel, etc, even if I never actually played a role in it (so far).
solatic
6 days ago
I think the reason the hole persists is due to the lack of production-ready client libraries for these configuration languages (e.g. Nickel) in Turing-complete languages and popular tools (e.g. Go, Kubectl, IDEs like VSCode and Jetbrains). Everything needs to be wired together with shell scripts and task runners. IDEs that offer autocompletion, smart functionality, and other first-class support for Kubernetes, Helm, Terraform only at best offer support for generic CUE or Dhall or Nickel via their LSPs.
I think if you could kubectl apply -f production.cue, momentum would start to shift.