Hacker News Reader

Comment by dnautics | Hacker News Reader

> declarative is more scalable and understandable.

If you don't have to debug your system in the large (why is my outcome not what I expect)

If your operators are written correctly and you don't have to debug your system in the small

What you’re saying is equivalent to “buggy declarative code is harder to debug than working imperative code.” Obviously that’s true, but not exactly a convincing argument that imperative is better than declarative.

Your underlying assumption is that it’s easier to write correct imperative configuration than it is to write correct declarative configuration. In my experience, this is not the case. Consider a basic task like provisioning a fleet of hosts and deploying some code to the fleet. In an imperative approach, you need two distinct steps. One for provisioning, and one for deploying. Both operations are multi-step processes that are required to be idempotent because the number of possible failures between the start of provisioning and the end of deployment is quite large. It’s not easy to write a system that does this, as there are a lot of steps that need to be enumerated via imperative scripts for both provisioning and deployment, and it’s even harder to do in a failure tolerant way.

Compare the above to a Kubernetes deployment. The entire configuration is 30 lines of yaml. There is no providing step. Kubernetes will make sure the resources you need are provisioned and it will do so in a failure tolerant way.

Nope. Buggy declarative code is harder to debug than buggy imperative code.

I think the core thing is that if you have a bug in the declarative code, it usually affects everything and can be fixed in the execution engine, or you didn't actually declare what you wanted but something else.

By contrast, bugs in imperative code can manifest simply because you happened to write it in such a way that relied on some assumption that no longer holds and your imperative code does something it should not do because its preconditions are invalid.

Declarative approaches are generally more robust because they by necessity tend to be designed to handle more diverse initial states and still reach the correct result.

You still are implicitly assuming it’s easier to write bug-free imperative configuration compared to declarative. It doesn’t really matter which is harder to debug if it’s much easier to write bug-free code using declarative code. Again, some specific examples that underpin your assumption would be helpful in making your argument more convincing.

Read beefwellingtons SQL EXPLAIN PLAN, comment. I've also watched my roommate have a four hour argument with her coworkers about one line in their kubernetes deployment[0]. I've also spent days trying to fix a declarative Ansible playbook, only to table flip and rewrite it from scratch in 20 minutes (this was a MySQL install-and-configure command where MySQL version had drifted underfoot).

[0] iirc this was not a bug in their kubernetes operator (or maybe it was, I don't recall exactly) but a situation where they didn't understand why their containers were exhibiting the anti affinity properties they were expecting out of their declarations.

edit: were not exhibiting the anti-affinity. They were trying to make sure distributed postgres replica nodes weren't on the same physical hardware, for obvious reasons.

This is an often overlooked thing.

Anyone who's had to do an EXPLAIN PLAN or equivalent to figure out why a SQL query is suddenly taking 40x the time to execute and return results can attest to this I think.

Reply on news.ycombinator.com