You must log in or register to comment.
TL;DR: the project is nice and welcome, most of development reasons seem straw man arguments (“I wanted to do it” would have been better).
Detailed comment (Wall of text)
I have some counter-arguments to the reasons of OP frustration with Ansible:
YAML based declarative DSL really stinks on complex tasks as it lacks the flexibility that imperative languages have.
Although this point can be agreeable, it doesn’t provide an example of what amount of flexibility someone (the author) could need. So this make me think “maybe OP wanted to use Ansible for some problem that Ansible cannot resolve”. Also, Ansible supports Jinja templates, which add expressiveness to it.
YAML is not even a programming language, and you gonna pay the price very soon.
This is goes with the previous point, and this is a subjective argument too: if YAML is enough for a task, there is no price to pay, at any time; if YAML is not enough, there has been a miscalculation during the tool choice.
To keep ansible code clean and simple, extra efforts are required, one need to refactor out all the complexity from YAML to python modules and this feels like “why I even start using YAML DSL”?
I agree that, without a lot of experience (myself included), Ansible code is hard to maintain. But, in my experience, most of the complexity can be abstracted by using templates. If there is the need of something more complex, maybe a script fits more the job.
Ansible reports are frustrating as I always need to add these debug tasks to show real STDOUT/STDERR emitted from commands, where it should just work out of the box.
Absolutely agree. A simpler way to debug or print stdout/stderr (such as a task-level option) would be welcome.
Ansible ties me to the idea of “running on a host,” where sometimes I need to run tasks not tied to hosts, yes, you can still use “ansible_connection=local” but this feels awkward.
I guess this is subjective, but IMO if it feels awkward it may not be the best way to do (still, there are some cases where it is the only way to follow).
The Web UI is nice and clean, I’d like to have one also in Ansible. This is surely a +1 for Sparky.
As for the example, from someone that does not know Raku (but who is a developer, i.e. me), it does not seem much simpler than an Ansible playbook.
I haven’t ever used Ansible but I have used a project that also made the boneheaded decision to use templated YAML. That cost me several hours of debugging…
This is goes with the previous point, and this is a subjective argument too: if YAML is enough for a task, there is no price to pay, at any time; if YAML is not enough, there has been a miscalculation during the tool choice.
Well, yeah I think he’s saying that Ansible is the wrong tool and he’s making a better one. It’s also not just that YAML isn’t “enough for a task”. It’s extremely error-prone and add unhygienic templates onto an already janky language is just asking for trouble.
most of development reasons seem straw man arguments … I have some counter-arguments
Tbf you agreed with half the points you quoted…
I think the biggest problem with this replacement is the choice of Raku. That’s a super niche and quite weird language that nobody is going to want to learn. I would have probably used Typescript or maybe Dart.
Well, yeah I think he’s saying that Ansible is the wrong tool and he’s making a better one. It’s also not just that YAML isn’t “enough for a task”. It’s extremely error-prone and add unhygienic templates onto an already janky language is just asking for trouble.
Fair enough, I guess I have never had to use Ansible for big enough projects where these kinds of error spring up more frequently.
Tbf you agreed with half the points you quoted…
Well, the only one that I agree completely with is the stdout/stderr one. All the others have some kind of caveat that prevents me to support OP claims.
In any case, on the language choice we are in agreement: as of now Raku is not a popular language, so requiring a user of the system to know the language cannot provide much appeal to the project.
In any case, on the language choice we are in agreement: as of now Raku is not a popular language, so requiring a user of the system to know the language cannot provide much appeal to the project.
FWIW, for this application, I’d say only knowledge of “baby” Raku is needed. And if you’ve had any exposure to “baby” Perl in the past, then you already have that.
Yeah I mean I knew Perl back in the 90s. I’m not super keen to relearn it just for this. Why not use a more mainstream language?
(I’m guessing the answer is “because I made this for me, and I want to try Raku” or something, which is fine.)