Port PADD to a new and more robust language.

[dschaper]

Is your feature request related to a problem? Please describe.

bash is great but it's close to hitting it's limits as far as extensibility and maintenance. I'm considering porting this to a new language and I'm looking for thoughts and ideas. My first thought is to use golang but that is a compiled language and would remove some of the transparency of the code. All the code would still be open source and available here with instructions to compile yourself if you felt that was more comfortable.

I may turn this in to a discussion topic if there are people interested in this or have other ideas and concerns.

[PromoFaux]

Was recently recommended these Go libraries for console stuff by @goblinfactory

• https://github.com/jroimartin/gocui
• https://pterm.sh/#/?id=%F0%9F%A7%AA-examples
• https://github.com/rivo/tview

May be of use here

[dschaper]

Thanks, I was going through a few tutorials with

https://github.com/spf13/cobra
and
https://github.com/manifoldco/promptui

[goblinfactory]

Go is a great language if you've come from C# ; you'll enjoy the simplicity and it will make you a better C# programmer.

Adam mentioned me by name, and this is the first time I've seen the code, so not familiar with the project history, just reading from the top, and then a quick peek at the project, (appears to be a single bash file for self evident simplicity and reviewability and trusty-ness) ,that makes perfect sense.

I think the concern about transparency is valid. While go binaries can be distributed as Brew binaries; if you already have Go installed, you can install utilities from source with a single command, go install {repo_url} and that installs it from source, so for all the go users that will run a future PADD written go, they'd most likely be doing it that way. (for security reasons).

my 2 cents;
Having taken a quick look at the bash script; running off a single config, I think the std lib flags package should be sufficient to get started with instead of cobra; and extra features like using Prompt UI might be better as another project that wraps the command line project, i.e just as a way to wizard config it "for you", thus keeping the core package size small for those who are happy to edit a config manually.

Here are some go references that I think would be relevant here;

Go standard library for parsing command line flags; start here
https://gobyexample.com/command-line-flags

The next level up from that accepting more complex command line options; as shown here
https://github.com/jessevdk/go-flags

Followed by more higher level abstractions like Cobra etc. Though the Go community frown upon you starting with a complex library until you've exhausted all simpler options first.

I will take a look at the projects, I have a good friend who keeps telling me to setup a pihole for my home network. This is a good nudge to go do that; maybe I can help out somehow.

cheers,
Alan

[dschaper]

Great! Thanks a ton for the helpful information. I've used the stdlib flags and it seemed a little limited. The go-flags may be helpful but thinking over things, I honestly don't see a whole lot of CLI arguments that need to be passed.

PADD essentially queries pihole-FTLs telnet API for status and some basic metrics and presents it in a dashboard like fashion.

And thank you for the idiomatic Go advice on additional libraries!

[subnut]

I think we should keep it a shell script, because that's more 'hackable'. Your executable is your source code, and your source code is your executable. Just tweak the code and run! No compiling needed.

Go is a nice language, but I think that for simple use cases like this one, it's better suited to be a single-file shell script.

Also, shell scripts have and advantage that you always have a REPL for it :)
And anybody using a UNIX-like system needs to know about the shell syntax, but not Go.

[goblinfactory]

Sounds like you need both; there's clearly a demand from users that are comfortable with bash scripts; and also for those who want to dive in and take this to the next level. If this becaomes a significant project then keeping it in bash would limit the pool of developers that would want to contribute; So I guess it depends on what your goals are. Or if that's even relevant, i.e. just do both; A "Go" project could be done "just for fun" and as an experiment, see what happens, see what it's like, see who uses it etc.