[harlowja]

It also seems pretty much the same as ansible (which suffers the same problems as you mentioned).

I pretty much agree with you, they should of provided 2 entrypoints IMHO, they can make there DSL and all that and make it (eventually) turing complete and at the same time they should just provide composeable objects in <some> language as well.

I've never quite figured out who the target audience is for these kind of DSL(s), is it people that can't program, or people that can't program well/at all (without adult supervision)?

[dkarapetyan]

I don't know either. Puppet, ansible, salt, and friends are in the same boat. The best part is that the special syntax doesn't buy them anything. They just end up being gimped languages for expressing some kind of dependency graph.

[bostik]

All configuration management systems suck.

They all suck in equal measure, but each in a different fashion. You can only try to pick the one tool that sucks the least for your particular use-case and hope that two years down the line you made the right choice.

[dkarapetyan]

This isn't much of an argument. That's like saying all programming languages suck and it's a crapshoot. It's not. There are design principles that work and scale to large scale systems and then there are things that don't.

As far as I'm concerned Chef is the right way to do configuration management. Everyone else with their YAML DSLs is doing it wrong. Expressing dependencies between resources does not require specialized external DSLs and sometimes you need to do imperative things to get to the end which is either impossible or just horribly convoluted with any tool that tries to hide complexity behind a markup/serialization language.

[hubert123]

Apparently these people think it makes it "simpler". Well I'm sorry but me looking up how to format things with yaml and no autoformat and no intellisense just isnt good and doesnt make things simple. Even xml with a backing xsd would be better than that, but that's apparently not cool enough anymore.

[dkarapetyan]

I forgot about the lack of auto-complete and the horrible error messages. At least with a library when I have a syntax error or something blows up I have a debugger and the actual language at my disposal to figure stuff out. No such things are remotely available with all these external DSLs. If even there is any semblance of error reporting.

Several human centuries of effort have been spent on improving these things (syntax highlighting, auto-complete, stack traces, error messages, interactive debuggers, etc.) and then all these DSL authors decide to just chuck it all out. Boggles the mind.

More than a few times Terraform has wrapped an error message from AWS in the hopes of being helpful while hiding all the details of the actual error message and no hints how to rectify things in the DSL.

[apatap]

Syntax highlighting and auto complete is available for HCL (The language used by Terraform)

e.g.

https://plugins.jetbrains.com/plugin/7808-hcl-language-suppo...

https://github.com/wholroyd/vscode-hcl

[bmurphy1976]

Which is great and all but like the op said our files are actually jinja2 templates because HCL just doesn't cut it.

[hubert123]

I had the same experience with ansible. It also wraps the responses in some ultra verbose json. I really just want to see the remote commands being executed, if you return them wrapped in some kind of format then you need to provide a gui for it. Otherwise it's all worse than before.

[tannhaeuser]

Would you know a recent tool based on XML + XSD (or RNG) in the space (I believe IBM had one like 10 years ago, but it got sacked because XML)? I've never been a fan of using markup languages for things other than text/semistructured data, but yaml/toml/json is such a huge step backwards that I'm having trouble recommending it.