cjbassi / gotop

A terminal based graphical activity monitor inspired by gtop and vtop

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Rust rewrite

cjbassi opened this issue · comments

edit: Rust port being worked on over at https://github.com/cjbassi/rtop. I plan to merge gotop PRs at least until rtop is feature equivalent, at which point I'll probably archive gotop.

Why rewrite in Rust?:

  • I personally prefer working in Rust
  • Rust is more difficult to learn but solves many of Go's shortcoming that I've encountered with gotop:
    • proper dependency management
    • generics
    • enforced thread safety
    • ability to embed files in the binary (colorschemes)
    • functional programming ergonomics
    • proper enums (enumerating keybinds, events, etc)
    • granular conditional compilation (not per file)
  • there's a lot of awesome Rust packages gaining in maturity: tui-rs, crossterm, etc
    • will get truecolor colorschemes

Wouldn't it be more appropriate to create a new repo for the Rust rewrite, and archive gotop?

That's a good question, I'll post 2 comments here and people can vote on which option they prefer.

Thumbs this comment up if you would prefer this repo be rewritten in Rust, possibly renaming the project, while creating a Go branch for the current source code only for reference.

Thumbs this comment up if you would prefer this repo be archived and a separate repo be created for a rust rewrite under a different name.

So it seems like creating a new project is the preferred course of action :) I've moved the port over to https://github.com/cjbassi/rtop. In the mean time I plan on getting to the gotop PRs at least until the port has feature parity (which may be a while) and then we'll see how things go from there.

Hey, @cjbassi -- if you're going to stop maintaining gotop, can you ping me to discuss a peaceful hand-over of maintenance of this project? I'm thinking, you still own it (as in, it's in your namespace), but give me access to push directly and manage pull requests. I'd prefer this against a fork; gotop has packages in several distributions and I'd like to minimize disruption.