prop(rhino-pkg): Drop rhinu-pkg in favour of a Go rewrite.

[ajstrongdev]

What feature would you like to see included in Rhino Linux?
I have become convinced that a rewrite of rhino-pkg in Go, rather than Nushell is not only more feasible short-term, but more scalable long term. Currently the development of rhino-pkg 2 (which we've dubbed rhinu-pkg) is currently being handled by a sole maintainer, @Elsie19, in Nushell. No other member of the Rhino Linux team knows Nushell to a confident enough ability to continue the development if @Elsie19 were to cease maintenance of it.

In contrast to this, multiple members of the Rhino Linux team, including myself and @oklopfer have knowledge of Go, and I would be more confident in the continued maintenance of rhino-pkg going forward.

Describe alternatives you've considered
The alternatives to this proposal would be to either continue with the development of rhinu-pkg, or to create it in another language such as Rust.

Additional context
rpkgo
rhinu-pkg

Lastly, I want to recognise the effort that @Elsie19 has put into the development of rhinu-pkg thus far, and this proposal is not intending to detract from that, rather I just have concerns about the long-term maintainability of the project if the rewrite in nushell were to continue ahead.

Please note: This is currently a proposal, and is subject to change. It is pertinent that if you have an opinion on the matter, that you comment and share it with us, as this could shape the future of Rhino Linux development.

[Elsie19]

My first immediate thought is that nushell isn't a difficult language to learn. If you understand how bash pipes work, it's on the whole just that, with very clear builtin tools to parse input and pipe to output. I would go as far as to say that Nushell is easier to learn than bash.

It's also based on Rust syntax, so if you know even a bit of rust, you won't have any trouble reading it.

The reason that rhinu took so long is because I was refactoring the codebase into something more maintainable. Rhinu could've been released a long time ago if I pushed it all into one giant file like the original, but that's not maintainable.

[ajstrongdev]

My first immediate thought is that nushell isn't a difficult language to learn. If you understand how bash pipes work, it's on the whole just that, with very clear builtin tools to parse input and pipe to output. I would go as far as to say that Nushell is easier to learn than bash.

It's also based on Rust syntax, so if you know even a bit of rust, you won't have any trouble reading it.

While you make a great point about it being easy to learn, the problem is that you are expecting people to learn something at all when developers already have knowledge of other languages such as Go, Rust and Bash.

Just because Nushell is "easy to learn" doesn't mean people will always have the time to, open source is volunteer work and our utilities should be written in a way that anyone with experience in XYZ language should be able to pick up maintenance of the program without having to learn anything additional. People are busy, why would they contribute to our project when it's written in some obscure lang that they have to then teach themselves if they wish to contribute?

[Azathothas]

Other than the barrier to entry & unfamiliarity with nushell,
It also doesn't compile to static executables:

• how to make a nuscript standalone executable? nushell/nushell#8481
• Compile-to-binary for nu scripts nushell/nushell#6469

Any package manager should have as little dependency as possible.
Bonus if it is completely independent.
alpine's apk or rather more appropriately debian's dpkg can bootstrap & recover systems from scratch.

I had written a more informal version at: https://discord.com/channels/1030820921235210371/1030820923198148640/1338192716152045649

[oklopfer]

I think it would be helpful to have a pros and cons list for each of the languages to help us determine which would be best. As we have discussed, really any of the 3 options (Go, Nushell, Rust) are more suitable than Bash is right now, but they all have their benefits and drawbacks.

[ajstrongdev]

In my opinion:

• Nushell will still allow for us to ship a -git version of the packages, which is a slight benefit if users would wish to modify the manager, but imho we should be shipping release binaries to end users regardless anyway.
• Go is rather suitable as a candidate if we do decide to go the compiled route. It's a fairly straightforward and simple language, and a large portion of developers within our own team already know Go.

[Elsie19]

I think it would be helpful to have a pros and cons list for each of the languages to help us determine which would be best. As we have discussed, really any of the 3 options (Go, Nushell, Rust) are more suitable than Bash is right now, but they all have their benefits and drawbacks.

Pros (non exhaustive list) for nushell are:

1. Parsing command output is literally what nu was made for.
2. It's a shell, so we can just call package commands without special syntax.
3. Since it's a shell, it's very easy to modify without needing to ever "recompile".
4. It requires less boilerplate to develop.

[ajstrongdev]

Pros of Go (non-exhaustive):

• Concurrency through goroutines would allow parallel execution of tasks, meaning it could open the door for multiple managers to download asynchronously
• Compiles to a static binary, can be shipped in a -bin pacscript.
• Rich and exhaustive standard library, and additional packages if required.
• Strong typing can reduce errors when compared to shell scripting languages.
• More people know go, meaning it'd be easier to find additional maintainers.
• Go has really good error handling.

[Elsie19]

Pros of Go (non-exhaustive):

• Concurrency through goroutines would allow parallel execution of tasks, meaning it could open the door for multiple managers to download asynchronously
• Compiles to a static binary, can be shipped in a -bin pacscript.
• Rich and exhaustive standard library, and additional packages if required.
• Strong typing can reduce errors when compared to shell scripting languages.
• More people know go, meaning it'd be easier to find additional maintainers.
• Go has really good error handling.

Just wanna mention two things:

1. We can do concurrent downloads if we wanted.
2. Nu has strong types, it's not like bash.

[ajstrongdev]

Just wanna mention two things:

1. We can do concurrent downloads if we wanted.

2. Nu has strong types, it's not like bash.

Okay that is useful information, did not know that. Thank you.

[Elsie19]

Also the pros list should be really about "how can your language specifically parse command output and work on that in a simple way".

[ajstrongdev]

Also the pros list should be really about "how can your language specifically parse command output and work on that in a simple way".

This I disagree with, there are more factors to weigh than just "how does the language do XYZ" because all languages are more than capable of being suitable for rhino-pkg, my concern is about long-term maintainability tbh.

[Elsie19]

Just wanna mention two things:

1. We can do concurrent downloads if we wanted.

2. Nu has strong types, it's not like bash.

Okay that is useful information, did not know that. Thank you.

Please look at https://www.nushell.sh/, because those things are either listed on the landing page or docs. If you're asking to drop my implementation, at least look at the language features before asking, because it seems that you don't actually know what nu can do.

[ajstrongdev]

I have taken a look at that before, I just forgot, however I do feel as though my point about go having a rich standard library & multiple additional packages, as well as ease of maintainability, to be paramount to the discussion. Considering the fact progress of rhinu-pkg was stalled significantly due to requiring us to create our own translation plugin for nu, it leads me to concerns about scalability.

[oklopfer]

FWD of our conversation from Discord:

@Elsie19 : tbf a lot of that was me being lazy; it took me a couple days to make the plugin, most of rhinu was either me being busy or burnt out. I completed it when I had free time.

@oklopfer : that doesn't detract from AJ's point though. AJ's point was

Considering the fact progress of rhinu-pkg was stalled significantly due to requiring us to create our own translation plugin for nu, it leads me to concerns about scalability.

because you were lazy and/or burnt out, and the only one who could rly work on it, this was exacerbated, and more importantly the point is that we had to create the plugin in the first place, it wasnt something that already existed (but should) - who knows how many more plugins we will end up having to write

@Elsie19 : if the language I wrote it in was rust instead of nu would we be here now asking to change the language? because I don't understand why AJ says nu is hard, it's literally just bash + rust

it wasnt something that already existed

also that was the last thing, the actual program was functionally done

@oklopfer : no, we would not be, but thats because rust already has the support that nu doesnt

the actual program was functionally done

i think you're thinking of it in the wrong way - the actual program is not at all functionally done, it barebones works. we want to build on top of it and add a lot more features, and we need a language ready to support that. nushell is great for what rpk does right now, in its weak and futile state

because I don't understand why AJ says nu is hard, it's literally just bash + rust

again its more about the lack of support/plugins/community actively working on it

@Elsie19 : but there is an active community, 5,000 in the discord alone

@oklopfer : you cant possibly say that the community size of nu is anywhere near bash, rust, or go; the point is that there are endless forums you can get community support from for everything else. nu is extremely niche - the others do not at all suffer from this, because they all have an insanely large community and user base

[ajstrongdev]

Yeah this is basically the exact point I wanted to make.