In this case right here, what's your counter-example, or what would you use instead of their specific approach?
No, or at least not often enough to be worth thinking about. It is of course possible to use abstractions badly, but the problems that business software has to solve are always fairly simple because they're human problems; human business processes were never that complex. So if a program looks really complicated, the overwhelmingly likely cause is failing to use appropriate abstractions.
> In this case right here, what's your counter-example, or what would you use instead of their specific approach?
As others have said, a result type would greatly simplify this code without sacrificing any safety. No doubt after such a simplification made the code shorter and easier to comprehend, further simplifications would become apparent.
It’s also an open source project, so if anyone wanted to throw up a branch with an example of simplification without sacrificing logic branch completeness that door is open. Code might even convince the k8s team to change what you think is misguided behavior.
Sometimes the best software is no software. Kubernetes exists to solve problems that people using better languages don't generally have.
> It’s also an open source project, so if anyone wanted to throw up a branch with an example of simplification without sacrificing logic branch completeness that door is open.
The "Please do not attempt to simplify this code" comment suggests otherwise. In any case, the team have chosen a language in which good solutions are not possible.
This statement doesn't make sense, and the arrogant tone just stinks of ignorance.
Kubernetes isn't perfect, but if there's better provider-agnostic language-agnostic way to dynamically scale an application written in heterogeneous languages across a cluster or on a competitive choice of cloud platforms with dynamic provisioning, I'd like you to tell us, and explain why it's better than Kubernetes.
Language agnosticism isn't something to discard lightly. Different languages have different strengths and weaknesses.
(The JVM startup can be a bit slow for scripting one-liners, particularly if you're running them on every file in a directory or some such. There was a time when I would switch to Python or Bash for those, but I realized I was wasting more time making mistakes in those languages than I ever saved at runtime)
That’s a falsifiable claim. Human problems / laws are some of the most difficult to code for, IMO. Examples: legal software, economics software, etc. Usually complexity increases as you delve out of the abstract and deal with real-life processes with humans.