I don't think there's a much nicer language when it comes to system configuration than a shell. I'm not sure why people want to write an extensive, complex program in a full-on programming language for simple tasks for which the shell and it's utilities were literally invented. The shell does a great job for managing your system already, and so far I've never had a better experience by making using a more complex language.
I've tried Ansible multiple times. Every time it seemed to cost more effort to do something simple, and once you start mixing OSs, things get much more complicated very quickly.
> It can stream shell commands so you've got all the usual sed awk etc
I can write a couple lines of yaml which includes the line of sed/awk/whatever, or just write the one line of sed/awk/whatever.
> And has a battle tested OS detection logic built in.
You can get pretty far with just checking /etc/os-release, and you'll need only a fraction of the code Ansible brings to do that. Ansible might do a _slightly_ better job, but the increased complexity is definitely not worth it.
> And can copy in different templates depending on OS.
Yes, it can do this, and I have done this. It's a lot of boilerplate YAML you'll need _every_ time you want to write any playbook. It's just not worth the ridiculous amount of hoop-jumping for something which seems to me to be a rather straightforward use case.
I've never used m4 directly, but it might be interesting to look at. I'll try to make some time to look around for information on this. If you have any pointers to get started, I'd be very interested.
One way to think about m4 is as form-substitution, eg. the ssh-config customization via sed.
Another is as text generator, eg. the classic sendmail config generator, where one writes m4 succinctly which in turn generates complex files.
From a 10,000 meter perspective, all the managed servers' config files are a projection from the central config repository. If that config is already an m4 file, then all that's left is finding the variant configs and handling them.
`make` is another nicety, as it handles the dependencies, eg. scp'ing the config and then HUP'ing the daemon only when that config changes.
That looks like the previous version shipped with Rakudo Star. A new version was published a very short while ago, so perhaps they will update to 2020.01 soon enough.
> It is a really nice language based off of all the tutorials and presentations I've watched. It just needs some better performance before I'll really start using it
I'm also very impressed in how the language is turning out. It's a pleasure to write and read. I know most people really don't like Unicode operators, but I find them to be very useful. They're short and concise, and allow those writing mathematical equations to stick to their regular symbols. And for those that don't know how to do Unicode on their OS/editor, there's ASCII equivalents.
Performance-wise, it seems to be fast enough for all my personal projects, and it's getting faster every release. Is there a certain piece of code that you want to have running within a certain amount of time? That would allow you (and Perl 6 devs) to have a goal to look at, and work towards.
Running grammars past very large datasets. You hear enough people talk about the performance and you decide to stay away a bit until things improve. I also have some numeric code and that is generally probably not a great P6 fit (more of a Python + Numpy thing).
As a general scripting language, P6 looks nice as a lot of features such as concurrency that are aren't super straightforward (Ex: python) seem to be dead simple in P6.
