4 ms·

Dhall continues to a be a glimmer of hope in this space. I agree that helm caused the entire space to distort. There is so little reusability in charts. Dhall

Dhall continues to a be a glimmer of hope in this space. I agree that helm caused the entire space to distort. There is so little reusability in charts. Dhall seems to be the start of reversing this, but I hesitate to mention it since the ergonomics are still rough. If YAML is the assembly language of k8s, Dhall looks like what you would write the compiler in.

gravypod 6y ago
Yea, anything that allows you to think in a higher-level than raw kube objects will save you a lot of time and heartache. For instance, if your application needs a redis cluster in helm you have to mess with subcharts/other headaches. In jsonnet it becomes `redis = import "redis"; redis.Cluster("my-app-name") { nodes: 10 }` or something similar. DRY configs make me very happy.
iso8859-1 6y ago
Given that the Dhall type system supports things that the other configuration languages do not, isn't it very hard to migrate to for a project like k8s? I don't see how they could support something in parallel to Dhall, and still enable all the features Dhall provides.
- __float 6y ago
  Dhall does have many features that can still "compile down" to YAML or JSON (or some others, too). Depending on this target language, some Dhall features are unavailable. I don't think OP meant Kubernetes is changing to Dhall, but that we'll see something like Dhall on top of Kubernetes YAML/JSON that catches on.
eaceaser 6y ago
IMO because Dhall is unique syntax to the vast majority of developers who have never done anything with Haskell or Elm or whatever, it’s a non starter for large case use. We use Starlark, where the syntax is familiar to anyone familiar with python. I like your analogy though. For us, the assembly language is using the k8s API directly in Golang. The “compiler” is the golang Starlark interpreter extended with our own config API, like you would implement in Dhall. It’s just in this case, you can implement it in Golang, which has much much better tooling than Dhall does. A typed compiler, debugger, IDE, unit tests.... so much easier to develop and maintain.

gravypod 6y ago

Yea, anything that allows you to think in a higher-level than raw kube objects will save you a lot of time and heartache. For instance, if your application needs a redis cluster in helm you have to mess with subcharts/other headaches. In jsonnet it becomes `redis = import "redis"; redis.Cluster("my-app-name") { nodes: 10 }` or something similar. DRY configs make me very happy.

iso8859-1 6y ago

Given that the Dhall type system supports things that the other configuration languages do not, isn't it very hard to migrate to for a project like k8s? I don't see how they could support something in parallel to Dhall, and still enable all the features Dhall provides.

__float 6y ago
Dhall does have many features that can still "compile down" to YAML or JSON (or some others, too). Depending on this target language, some Dhall features are unavailable. I don't think OP meant Kubernetes is changing to Dhall, but that we'll see something like Dhall on top of Kubernetes YAML/JSON that catches on.

eaceaser 6y ago

IMO because Dhall is unique syntax to the vast majority of developers who have never done anything with Haskell or Elm or whatever, it’s a non starter for large case use. We use Starlark, where the syntax is familiar to anyone familiar with python. I like your analogy though. For us, the assembly language is using the k8s API directly in Golang. The “compiler” is the golang Starlark interpreter extended with our own config API, like you would implement in Dhall. It’s just in this case, you can implement it in Golang, which has much much better tooling than Dhall does. A typed compiler, debugger, IDE, unit tests.... so much easier to develop and maintain.