Bpytop: Linux/macOS/FreeBSD resource monitor | Hacker News Reader

FreeBSD resource monitor

github.com

88 pointspantalaimon19 comments

The same author has a newer version of the utility called btop (written in C++): https://github.com/aristocratos/btop .

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

So... performance was sub-optimal, hence the rewrite in C++.

I would too.

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.

But yeah, I'd be interested in hearing specifics.

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.

well, you're not wrong, but there are lots of libraries/wrappers around that interface that work pretty well

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.

would be interesting to know what was easier / harder since it's one of the rare cases of writing pretty much the same program in these two languages

It isn't even just the same program in two languages!

He started it all with a bash version (named bashtop, here: https://github.com/aristocratos/bashtop)!

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).

It's kind of hilarious to see hacker news discover the second iteration in the series of three rewrites. This started with bashtop, then bpytop, and now it's btop.

There are probably dozens of HN stories discussing those too.

Can I call this a dupe? :)

Should we start a betting pool on how long it'll take him to rewrite it yet again in Rust? I give it a year.

Not sure why he would do that. Seems like the issue was more or less bad performance, and that has been fixed by using C++.

Memory management bugs are the only reason I could think of to switch from C++ to Rust

Bottom exists[0], if you're looking for a rust-based resource monitor it's pretty much the best in the biz.

[0] https://github.com/clementtsang/bottom

x86 assembly re-write in 3.

Reply on news.ycombinator.com