10
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 31 May 2024
10 points (100.0% liked)
Raku
157 readers
2 users here now
A place for all things related to the Raku® Programming Language—an open source, gradually typed, Unicode-ready, concurrency friendly programming language made for at least the next hundred years. Please join us, for programming should be optimized for Fun and Profit!
Links
We are a bunch of volunteers developing the Raku Programming Language as the Open Source language of the future.
We also develop tools, web-services and applications written in the Raku Programming Language.
We try real hard to be nice to each other. You can help too! The only requirement is that you know how to be nice to all kinds of people (and butterflies 🦋). And don't be afraid to ask if you do not understand something.
founded 1 year ago
MODERATORS
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: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.
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.
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.
Absolutely agree. A simpler way to debug or print stdout/stderr (such as a task-level option) would be welcome.
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...
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.
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.
Fair enough, I guess I have never had to use Ansible for big enough projects where these kinds of error spring up more frequently.
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.
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.)