43 ms·

Took the words out of my mouth. This is exactly what I fear will happen. If you look at the YAML some people produce and extrapolate that to one of the most dy

Took the words out of my mouth. This is exactly what I fear will happen. If you look at the YAML some people produce and extrapolate that to one of the most dynamic languages available, it is going to get ugly. Programming languages for config are better, and I will throw up if I ever have to see “list comprehensions” and null checks in Terraform ever again, but it requires people who can code. If you simply replace YAML with Python and that’s folks’ first time using a normal language, it won’t work. Hence I’m happy to stay with YAML mostly, in such a scenario.

dvdkon 3y ago
Then again, the YAML of Ansible or various CI platforms basically is code. People who already successfully write that will do well enough in Python. (Not that YAML isn't used in plenty of non-code usecases.)
- diarrhea 3y ago
  It is code, but without any of the aspects usually ascribed to code. Abstraction, tools like dependency injection (fancy term, but simple and highly important concept), more complex looping (not just `for each item do`; `for each item do, if item...` etc. are needed). Unit tests? Not to speak of tooling support. I can write a Python application with the strictest type settings and have mypy do a lot of heavy-lifting for me, before even running the app once. A bit like Rust. Check out the typestate pattern for what I am on about. It's invariants enforced in the type system, by the compiler. Impossible to misuse: your code simply won't compile. All of that is impossible to have if your types are strings only, with the odd bool and float inbetween. I will accept that we cannot have ops people be at least medium-grade developers, which would be needed to apply these topics (I consider myself an in-between, leaning dev). That's simply infeasible. It's two different worlds. I will not accept the premise that these things aren't objectively better though! They're practically inachievable, sadly (or at least a decade away). So no, in that advanced sense, YAML is not code. And if you can do YAML, yes you will get Python syntactically correct with a little practice. That is only 5% of the way though. Note I'm also not advertising for Enterprise Java-level of code... but more than "YAML but in Python".
XorNot 3y ago
I disagree strongly: configuration should not be code. Code should be code. Configuration should be static and simple. It is not trivial to tell what code is doing, and as soon as your configuration is code then really you're developing a new application which implements another configuration language.
- diarrhea 3y ago
  Sure, if your infrastructure landscape is describable statically, that's how it should be done. Most scenarios nowadays are _not_ like that anymore. There isn't 5 servers next door, there's 300 serverless whatevers half a globe away. Are you going to have 300 list entries, 230 of which nigh identical but 70 subtly different? Trivial in code, almost impossible to express statically.
  - XorNot 3y ago
    What you're describing though is a configuration variability which would be expressable by a static tagging regime - still simple. If your configuration is getting more complex then that though, again, it's not really configuration anymore - it's a management application which needs to be developed and treated like that. And why it's that complicated should be re-evaluated - i.e. how come this is "configuration" and not something the application detects for itself? Why is it being surfaced to the user (operator) at all?

dvdkon 3y ago

Then again, the YAML of Ansible or various CI platforms basically is code. People who already successfully write that will do well enough in Python. (Not that YAML isn't used in plenty of non-code usecases.)

diarrhea 3y ago
It is code, but without any of the aspects usually ascribed to code. Abstraction, tools like dependency injection (fancy term, but simple and highly important concept), more complex looping (not just `for each item do`; `for each item do, if item...` etc. are needed). Unit tests? Not to speak of tooling support. I can write a Python application with the strictest type settings and have mypy do a lot of heavy-lifting for me, before even running the app once. A bit like Rust. Check out the typestate pattern for what I am on about. It's invariants enforced in the type system, by the compiler. Impossible to misuse: your code simply won't compile. All of that is impossible to have if your types are strings only, with the odd bool and float inbetween. I will accept that we cannot have ops people be at least medium-grade developers, which would be needed to apply these topics (I consider myself an in-between, leaning dev). That's simply infeasible. It's two different worlds. I will not accept the premise that these things aren't objectively better though! They're practically inachievable, sadly (or at least a decade away). So no, in that advanced sense, YAML is not code. And if you can do YAML, yes you will get Python syntactically correct with a little practice. That is only 5% of the way though. Note I'm also not advertising for Enterprise Java-level of code... but more than "YAML but in Python".

XorNot 3y ago

I disagree strongly: configuration should not be code. Code should be code. Configuration should be static and simple. It is not trivial to tell what code is doing, and as soon as your configuration is code then really you're developing a new application which implements another configuration language.

diarrhea 3y ago
Sure, if your infrastructure landscape is describable statically, that's how it should be done. Most scenarios nowadays are _not_ like that anymore. There isn't 5 servers next door, there's 300 serverless whatevers half a globe away. Are you going to have 300 list entries, 230 of which nigh identical but 70 subtly different? Trivial in code, almost impossible to express statically.
- XorNot 3y ago
  What you're describing though is a configuration variability which would be expressable by a static tagging regime - still simple. If your configuration is getting more complex then that though, again, it's not really configuration anymore - it's a management application which needs to be developed and treated like that. And why it's that complicated should be re-evaluated - i.e. how come this is "configuration" and not something the application detects for itself? Why is it being surfaced to the user (operator) at all?