34 karma · joined February 9, 2010
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.
Essentially the config language implementation would be the same logic that a helm chart would do, but you’re writing the logic in Go versus a text templating engine. You can easily unit test parts and rely on the compiler to catch basic mistakes. Way better than templating YAML.
We also provide escape hatches so people can easily patch the resources before they get serialized to YAML. People can use that to customize our standard deployment config however they want.
So far this has worked very well and been extremely easy to maintain.
A related question I want to ask is: what is inherent about software that makes it not okay to have restrictions on modifications where lives other than the owner's may be at stake? I see other comments here that say things like "oh these machines should have mechanical limiters etc. that prevent them from being dangerous." But isn't that essentially the same thing, just implemented in hardware and not software?
I'd like to note that I'm not saying that John Deere is in the right here. I just feel that the argument in the parent comment is, for lack of a better word, inhumane.
In other words, I believe we should laud all attempts to build a culture of civic engagement, no matter what your political beliefs are or your personal background. The next step is to help find ways for that civic engagement to be generally helpful rather than harmful.
full disclosure: i work at one of the companies named on this proposal