- Not turing complete yet sufficiently expressive to DRY
- Define schema and data with the same language, in a separate or same file. With union types.
- Generate YAML or JSON. Can validate itself, or a YAML or JSON file.
The biggest drawback being the only implementation is currently in go, meaning you may have to subprocess of ffi.
then it generates json files for each application for a tool that will create xml definitions which then are applied to a xls which the architects own, to spit out a yaml that we use to apply our helm charts. the charts deploy a k8s client which then interact with the main cluster via json using the api.
took a while, but we are using the best tool for each job.
Your API should clearly be using protobuf.
I find cue very ergonomic. Also it treating both types and values as values is very neat. You write your types and your values in the same syntax and everything unifies neatly. but I sometimes miss its lack of functions.
Cue also being to ingest protobuf definitions and openapi schemas makes it very quick and easy to integrate with your project. Have a new Kubernetes CRD you want to have type-checked in cue? No problem just run `cue get go k8s.io/api/myapi/v1alpha1` and off you go you have all your type definitions imported from Go to Cue!
Especially for k8s this makes for very fast development and iteration cycle.
I've wanted to take a look at https://nickel-lang.org/ which is a "what if cue had functions" language. but to be honest Cue kind of serves my needs.
Everyone wants type-safety, but no one wants to wait for the type-checker :)
Maybe in this case dhall with type checks equivalent to dhall would be slower, but I notice in many places people say "strong type-checking is valuable" while still expecting similar compile times as languages with weaker type systems.
And even then, they won't exactly pin point the problem, rather express their general frustration, without realizing that the dynamic system they used had indeed some great properties and were not popular for no reason.
I'm conflicted honestly. I find with dynamic languages it's easier to just spin your wheels and move quickly in the hole you are in.
With typed languages its easy to feel you are making less progress because the feedback loop can be longer, but generally the pieces you build are more likely to work correctly.
For me Haskell and ghci repl gives good properties from both areas, especially with something like Rapid for keeping state over repl reloads.
- It tends to make things less declarative.
- You lose locality of behavior, which is very useful in configuration.
Also, nickel doesn't support injecting data into the nickel file, so external program can't set variables, query a database and pass the result to the conf file, etc.