TL;DR: Salt is complex, multi-purpose tool, with event-driven orchestration and remote execution engine capabilities. In other words, it implicitly does what Ansible can do, plus many other things.
What I personally like the most is the ease to develop and extend features, vs., e.g., a clogged DSL as many popular tools (unfortunately) impose.
Yes, I know, and I completely agree. It was meant initially to be a pun, and nobody expected back then the library would eventually so much traction.
Even worse, I personally was giving a talk in Vietnam a couple of years ago, and you can probably imagine that I felt like an ass.
It has been discussed indeed, but unfortunately nobody volunteered yet to take the entire work of re-documenting everything and many other things that have to be done. But it's definitely something intended for the future.
From what I heard (I never had so many devices to manage myself), Salt can scale nicely when managing a very large number of devices - see for example this story from LinkedIn: https://s.saltstack.com/saltstack-at-web-scale-better-strong.... However, they're using it in the "classical" topology which is agent based. For non-agent base, you may consider looking into Salt-SSH: https://docs.saltstack.com/en/latest/topics/ssh/. Hope this helps!
Such a sad place, makes me feel bad whenever I have to go there. This is one of the main reasons I cut my travels to SF, I just can see that poverty, it's against my life principles.
I had prior experience with other programming / scripting languages, and picking Python up felt very natural.
I started with Mark Lutz's Learning Python (http://shop.oreilly.com/product/9780596513986.do) about 10 years ago.
In the meanwhile I've been an active contributor to large Python-based open source projects, e.g., Salt (https://github.com/saltstack/salt) which not only that it helped me get feedback from people with a tremendous experience, but also reading through the code taught me good practices and many good ways to solve various problems.
A few months ago I started reading Luciano Ramalho's Fluent Python (http://shop.oreilly.com/product/0636920032519.do) which is just beautifully written and with a wide variety of topics for a deeper look inside Python internals.
I agree with you. The main goal was for who's interested, to give some pointers on where to look for further details regarding the topics in cause.
Anyway, I hope this video helps https://www.youtube.com/watch?v=sMZd84_a3R0.
I'm not entirely sure I understand you. Do you find it bad that there are several options?
I had the feeling that YAML is the one that addresses your criticism ("I like YAML as configuration file language, but it's terrible for DSLs.").
And yes, I do use the python one and I am very happy with it.
The YAML is the default, and it's what you find examples and support for (Stack Overflow and so on)
Pro tip: if they are YAML on StackOverflow, you don't have to copy-paste them, but more rather translate them to the representation that satisfy your high requirements.
The overlap of capabilities is between StackStorm and Salt --
the later has many orchestration capabilities. For event driven ops it can even be used alone. I don't want to say that one is better than the other, but this comparison does not surprise me at all.
As a friend (big Ansible fan otherwise) would say: "Ansible is just a glorified bash script; nothing more, nothing else". Without making it a bad product, Ansible is that one limited to CM only.
Without being a comparison the other tool(s), I would make a point regarding to your blocker, which actually it shouldn't be a blocker.
Many folks miss one important point: Salt's renderer interface is also pluggable. There are quite a few choices for you: https://docs.saltstack.com/en/latest/ref/renderers/index.htm.... For data representation you can choose between: yaml, yamlex, json, json5, hjson, or even pure python. Nothing else can be more flexible than pure python. But, of course, this approach also has its drawbacks. Anyway, if none of them suits your needs for non-terrible DSL, you can even implement your own DSL, your own renderer.
All you have to do is adding few characters at the top of your pillar, i.e. #!json or #!json5 or even #!lobster.
So where is the limitation again? In reading documentation I guess.