PROPOSAL: V3 Collaborative effort? - move to golang-based CLI

[ChronosMasterOfAllTime]

@ankitcharolia I like the idea of a go-based CLI. However, your version isn't fully-featured like the goenv we are maintaing and adding features. I would like to propose that we collaboratively create a V3 version. Here's what I would like to see:

• Dynamically show and build a directory of the supported versions for a user's OS + Arch
  • e.g. if user is ARM based, only pull versions available for that
• Auto-adding the GOROOT/bin and GOPATH/bin to the head of the user's PATH in their shell profile to override any installed system version
• Add golang unit tests to replace BATS
• Continue to be feature-forward (non-breaking changes)
  • Ensure go.mod file is respected
  • maintain all current feature flags/environment variables
  • incorporate the homebrew auto bump with multi OS support
    • necessary as now we are dealing with OS+Arch-specific compiled binaries instead of relying on the user's shell
  • Keep using release drafter for version maintenance
  • Pre-release will trigger go-releaser action; release publish will trigger homebrew auto-bump.
• STRETCH: Compile unsupported golang versions

@syndbg What do you think about this?

We could greatly simplify the repo by using a higher-level language such as golang. I am well-versed (5+ years) in a lot of the advanced capabilities of golang.

We can create a milestone for this effort. I would welcome anyone else who has golang experience to contribute to this as well.

[syndbg]

I'll go thru this in the weekend and write back a more detailed response.

First and short impressions are that initially I opted for pure bash to be easily distributable on Linux machines and easily updatable via a simple git pull.

As years go by, perhaps creating a golang cli is a step in the right direction.

We have to consider plugin support, that happened to be in bash previously.

[findgo]

I find similar implement. goup base go cli, goup-rs base rust cli.