Im really excited about cuelang what is everyone else keeping an eye on?
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.
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.
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.
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
I think if you could kubectl apply -f production.cue, momentum would start to shift.
Still, that's what i want. Give me types (like Nickel) to validate APIs, but also give me easy inspection of values without manually jumping through pointers (function calls) like it's 1985 or something.
Ps, please for the love of god give me the ability to use Nickel instead of Nix. It's been such a long wait.
Multiline strings are m%" ... "% - why? having to match reversed difficult to remember magic glyph sequences is such an arse. Like C++'s raw strings. Awful. Python clearly got this right. Or you could just copy Rust and not even have special syntax for multiline strings. Why do you need it?
String interpolation is "... %{foo} ..." - why? Do they take delight in avoiding what other people chose? What was wrong with "... ${foo} ..."? You just wanted to make me have to remember 3 different string interpolation syntaxes?
They still inexplicably use `let ... in` rather than the much more beginner friendly and just plain nicer `let ...;`
I've only scratched the surface of course but the surface wasn't encouraging. Let me see if you still declare functions in a weird way... checks Well, it's a lot better but they still have inexplicably avoided separating arguments with commas which is obviously going to bite them in the arse when they want to add type annotations.
Still, I've been following Dhall, Jsonnet, Cue and all of them seem to have big issues too so I won't count Nickel out.
Is this the JSON data model? There are places I’ve seen this fall apart: very large and very small numbers, nulls, empty objects / arrays. How confident are you that every participant in your data interchange handles all these cases the same way? I’m suspicious of libraries that assume only they will handle your JSON.
Edit: just remembered another one. I had to deal with the fallout from a JSON serializer that dropped leading zeros from floating point numbers smaller than one, to save space.