7 ms·

> With "declarative" I still have to find out what's the intuition WHY it's supposedly better, Declarative is better because you write what you want to _have_

> With "declarative" I still have to find out what's the intuition WHY it's supposedly better, Declarative is better because you write what you want to _have_ not what you want to change, which means you need implicit knowledge of the state of the system, and leave the complexities of figuring out the in between to the tool you're using.

jen20 5y ago
As someone who has spent the last 7-8 years working on declarative infrastructure tooling: this is only better if the tool can work out how to get from where things are to where you want them to be without being destructive. It’s not like these tools are composing pure functions, sadly.
- ClumsyPilot 5y ago
  > this is only better if the tool can work out how to get from where things are to where you want them to be That's a bit like sating car is only better than a horse if the engine works. The tool has one job, They do ofcourse fail regularly, I feel that devops tools are 10 years behind our development tooling
  - jen20 5y ago
    Part of the reason they fail so regularly is because so many are wedded to the declarative model, in order that they don't have to understand what they are managing and how it operates.
cle 5y ago
The problem with most black-box declarative interfaces is that you often do care about how things will happen. The real-world limitations often leak through the declarative interface, because you have to care about things like performance, or do things that don't quite fit into the opinionated declarative interface, or have other weird constraints that the authors didn't think of. And then you're in a world of pain, where you have to not only know how to do what you want, but then also how the system will map from declarative->imperative, and then how to massage your declarative input so that it does the right imperative thing. And your teammates too. And you've all got to think about it every time you change the code or upgrade. I've run into this problem in nearly every declarative system I've ever used (examples: SQL, Prometheus, infrastructure-as-code frameworks, dependency injection frameworks, ORMs, k8s, and so on). Neither approach is "better". They have tradeoffs.
- jolux 5y ago
  > The real-world limitations often leak through the declarative interface, because you have to care about things like performance, or do things that don't quite fit into the opinionated declarative interface, or have other weird constraints that the authors didn't think of. But this is the case with opinionated imperative interfaces as well. It's irrelevant to the declarative vs imperative issue. This is a fundamental aspect of abstractions. There will always be things you can't do unless you're writing assembly on bare metal. And even then, assembly is an abstraction over microcode, and what the actual hardware is doing.
  - deleted 5y ago
    [deleted]
  - cle 5y ago
    I think it gets worse as an interface gets more declarative and tries harder to hide machinery and state (or tries less to expose it), either on principle or because it allows for extra safety or optimizations or evolution.
  - nfw2 5y ago
    Any API can have issues, but an imperative api has some advantages in my opinion. The boundaries of an imperative api are atomic and easily well-defined. When something goes wrong, it is possible to look at the methods individually and figure out exactly where expectations and reality diverged. With a declarative system you just put out everything there as one big chunk of state and hope the right thing happens. When the wrong thing happens, it's usually not clear if the problem is a bug with the engine or your understanding of it, and also not clear how to go about determining where the problem is. To be clear, I am not totally against declarative systems, but I would be hesitant to use any declarative system if it isn't mature and well-tested, documented with priority, and in a space where the use cases are predictable.
- deleted 5y ago
  [deleted]
- andrewjl 5y ago
bigcat123 5y ago
ryan_lane 5y ago
Except that with k8s, it's somewhat declarative. A number of things are immutable, or they're mutable, but will never be picked up if they change. So, you have to jump through hoops in those spots to make things declarative, like ensure things have unique names (like config maps with mounts that have sub keys), and orchestrate pod restarts. Kustomize/argo will do this orchestration for you, in a way that makes your config look like it's declarative. Also, you really do need to know how things are going to change when they're changed. By default when you update your deployments in k8s, you're probably going to have a brief amount of downtime. Argo rollouts and such let you define this declaratively, in a way that avoids downtime, but again, more complexity.

jen20 5y ago

As someone who has spent the last 7-8 years working on declarative infrastructure tooling: this is only better if the tool can work out how to get from where things are to where you want them to be without being destructive. It’s not like these tools are composing pure functions, sadly.

ClumsyPilot 5y ago
> this is only better if the tool can work out how to get from where things are to where you want them to be That's a bit like sating car is only better than a horse if the engine works. The tool has one job, They do ofcourse fail regularly, I feel that devops tools are 10 years behind our development tooling
- jen20 5y ago
  Part of the reason they fail so regularly is because so many are wedded to the declarative model, in order that they don't have to understand what they are managing and how it operates.

cle 5y ago

The problem with most black-box declarative interfaces is that you often do care about how things will happen. The real-world limitations often leak through the declarative interface, because you have to care about things like performance, or do things that don't quite fit into the opinionated declarative interface, or have other weird constraints that the authors didn't think of. And then you're in a world of pain, where you have to not only know how to do what you want, but then also how the system will map from declarative->imperative, and then how to massage your declarative input so that it does the right imperative thing. And your teammates too. And you've all got to think about it every time you change the code or upgrade. I've run into this problem in nearly every declarative system I've ever used (examples: SQL, Prometheus, infrastructure-as-code frameworks, dependency injection frameworks, ORMs, k8s, and so on). Neither approach is "better". They have tradeoffs.

jolux 5y ago
> The real-world limitations often leak through the declarative interface, because you have to care about things like performance, or do things that don't quite fit into the opinionated declarative interface, or have other weird constraints that the authors didn't think of. But this is the case with opinionated imperative interfaces as well. It's irrelevant to the declarative vs imperative issue. This is a fundamental aspect of abstractions. There will always be things you can't do unless you're writing assembly on bare metal. And even then, assembly is an abstraction over microcode, and what the actual hardware is doing.
- deleted 5y ago
  [deleted]
- cle 5y ago
  I think it gets worse as an interface gets more declarative and tries harder to hide machinery and state (or tries less to expose it), either on principle or because it allows for extra safety or optimizations or evolution.
- nfw2 5y ago
  Any API can have issues, but an imperative api has some advantages in my opinion. The boundaries of an imperative api are atomic and easily well-defined. When something goes wrong, it is possible to look at the methods individually and figure out exactly where expectations and reality diverged. With a declarative system you just put out everything there as one big chunk of state and hope the right thing happens. When the wrong thing happens, it's usually not clear if the problem is a bug with the engine or your understanding of it, and also not clear how to go about determining where the problem is. To be clear, I am not totally against declarative systems, but I would be hesitant to use any declarative system if it isn't mature and well-tested, documented with priority, and in a space where the use cases are predictable.
deleted 5y ago
[deleted]
andrewjl 5y ago

bigcat123 5y ago

ryan_lane 5y ago

Except that with k8s, it's somewhat declarative. A number of things are immutable, or they're mutable, but will never be picked up if they change. So, you have to jump through hoops in those spots to make things declarative, like ensure things have unique names (like config maps with mounts that have sub keys), and orchestrate pod restarts. Kustomize/argo will do this orchestration for you, in a way that makes your config look like it's declarative. Also, you really do need to know how things are going to change when they're changed. By default when you update your deployments in k8s, you're probably going to have a brief amount of downtime. Argo rollouts and such let you define this declaratively, in a way that avoids downtime, but again, more complexity.