4 ms·

This is where I usually pitch in with "Have your heard of CUELang, our lord and savior?": https://cuelang.org/ https://cuelang.org/ - Not turing complete yet s

This is where I usually pitch in with "Have your heard of CUELang, our lord and savior?": https://cuelang.org/ https://cuelang.org/ - 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.

1oooqooq 3y ago
we have a pipeline that ingest very concise cuelang files. 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.
- ljm 3y ago
  just throw in a kafka cluster so you can pipe each step through an event bus and you'll have an enterprise-grade deployment setup
- BiteCode_dev 3y ago
  You used JSON twice, how casual. Your API should clearly be using protobuf.
planede 3y ago
How does it compare to dhall?
- arianvanp 3y ago
  Dhall's lack of any form of type inference makes it very verbose and difficult to refactor in my opinion. (I'm the author of dhall-kubernetes and never ended up using it in production; funnily enough). Dhall is also extremely slow. We had kubernetes manifests that took _minutes_ to type-check. Cue is basically instant. This matters a lot to me. 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/ https://nickel-lang.org/ which is a "what if cue had functions" language. but to be honest Cue kind of serves my needs.
  - letmeinhere 3y ago
    Speaking of Nickel, they've got a great document detailing the reasons for their design (for example why they chose not embed in a general-purpose language like Pulumi) and how Nickel compares to other config languages like Dhall and CUE: https://github.com/tweag/nickel/blob/master/RATIONALE.md https://github.com/tweag/nickel/blob/master/RATIONALE.md
  - ParetoOptimal 3y ago
    > Dhall is also extremely slow. We had kubernetes manifests that took _minutes_ to type-check. Cue is basically instant. 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.
    - BiteCode_dev 3y ago
      People always undervalue the beauty of a short feedback loop until it's taken away from them. 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.
      - ParetoOptimal 3y ago
        I don't disagree with that either :) 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.
  - BiteCode_dev 3y ago
    Functions are a nice to have, but: - 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.
- gregwebs 3y ago
  Cue was designed very much with k8s in mind and developed tutorials and integrations for it early on. Dhall was designed pre-k8s. Dhall had to introduce a defaults feature: before that it was completely unusable for k8s. Dhall has functions, which are natural to programmers- particularly from an FP background, Dhall would be trivial to start using. Whereas it takes some getting used to cue's unifications- but there is enough documentation and integration for getting going with k8s to make up for it. Dhall has unique features for stably importing configurations from remote locations.

1oooqooq 3y ago

we have a pipeline that ingest very concise cuelang files. 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.

ljm 3y ago
just throw in a kafka cluster so you can pipe each step through an event bus and you'll have an enterprise-grade deployment setup
BiteCode_dev 3y ago
You used JSON twice, how casual. Your API should clearly be using protobuf.

planede 3y ago

How does it compare to dhall?

arianvanp 3y ago
Dhall's lack of any form of type inference makes it very verbose and difficult to refactor in my opinion. (I'm the author of dhall-kubernetes and never ended up using it in production; funnily enough). Dhall is also extremely slow. We had kubernetes manifests that took _minutes_ to type-check. Cue is basically instant. This matters a lot to me. 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/ https://nickel-lang.org/ which is a "what if cue had functions" language. but to be honest Cue kind of serves my needs.
- letmeinhere 3y ago
  Speaking of Nickel, they've got a great document detailing the reasons for their design (for example why they chose not embed in a general-purpose language like Pulumi) and how Nickel compares to other config languages like Dhall and CUE: https://github.com/tweag/nickel/blob/master/RATIONALE.md https://github.com/tweag/nickel/blob/master/RATIONALE.md
- ParetoOptimal 3y ago
  > Dhall is also extremely slow. We had kubernetes manifests that took _minutes_ to type-check. Cue is basically instant. 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.
  - BiteCode_dev 3y ago
    People always undervalue the beauty of a short feedback loop until it's taken away from them. 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.
    - ParetoOptimal 3y ago
      I don't disagree with that either :) 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.
- BiteCode_dev 3y ago
  Functions are a nice to have, but: - 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.
gregwebs 3y ago
Cue was designed very much with k8s in mind and developed tutorials and integrations for it early on. Dhall was designed pre-k8s. Dhall had to introduce a defaults feature: before that it was completely unusable for k8s. Dhall has functions, which are natural to programmers- particularly from an FP background, Dhall would be trivial to start using. Whereas it takes some getting used to cue's unifications- but there is enough documentation and integration for getting going with k8s to make up for it. Dhall has unique features for stably importing configurations from remote locations.