I would really love to read something about the limitations of python and why he decided to redo the whole thing in c++ instead of say, cython, but I couldn't find any explanations as to why.
I personally much rather prefer using utilities written in Go, Rust or C/C++ because they do not depend on a specific version of an interpreter/module so they are quite easier to install and it's way less likely to bork them. This happens to me all the time with Python and Perl applications and it's quite an hassle.
It's by no means perfect but it is possible to ship the runtime with the program. Most programs don't but it is possible.
The inverse of this is the problem that I often run into in niche areas with C/C++ programs where they require pretty specific versions of dependencies. The most obvious one I know is within the GIS space where getting a toolchain to to run often involves hunting down specific versions of many C/C++ dependencies or just giving up and running someones docker image (which I'd rather not do).
I have not run into this with go or rust (although I don't run that many rust programs that I know of).
I've used the python and bash versions and they both were slow. If you keep on scrolling down list of processes, it used to get stuck from time to time during cpu usage graph updates. It was so annoying for me that I never really used bpytop instead of htop which was much more responsive. current c++ version feels really responsive like htop
I have the intuition that system-related programs tend to prefer C (and friends) for API compatibility: you can access all the syscalls no matter the ABI or weird memory semantics or even callback requirements. In theory, every language should have a standard library that exposes almost all of the system API surface, but in practice there's a long tail of awkward to implement and seldom-used API surface that most standard library writers just shrug their shoulders at.
On Linux at least, the relevant API for reading this sort of data is... open up specific files in /proc and parse the often poorly-documented textual output to get the information you need. Which happens to be the kind of thing that C/C++ don't do very well at all, at least in comparison to languages like Python. Although I think Linux is the outlier in this regard.
Yeah, probably to scratch an itch. The monitoring tool was first written in Bash, then rewritten in Python and now is getting rewritten in C++. I am sensing a pattern now. I really hope if he or somebody else maintain the Python version though.
Writing something the second time is almost always easier; the notable exception is when you try to also make it way more general (second system effect).
