10
top 5 comments
sorted by: hot top controversial new old
[-] asperan@programming.dev 3 points 5 months ago

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.

[-] FizzyOrange@programming.dev 2 points 5 months ago

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.

[-] asperan@programming.dev 2 points 5 months ago

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.

[-] lizmat@programming.dev 2 points 5 months ago

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.

[-] FizzyOrange@programming.dev 2 points 5 months ago

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.)

this post was submitted on 31 May 2024
10 points (100.0% liked)

Raku

157 readers
1 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