There's also `progress` which works for tools mainly operating on a single file, but unlike `pv`, you don't have to start the tool differently. It'd e.g. work nicely for the `gzip` example. Just call `progress` on a different terminal while `gzip` is running.
I was curious on how that’s supposed to work, so I took a quick look: It scans /proc for known commands, then looks up file descriptor information via their fd/fdinfo directory to get size/seek positions and then shows a percentage of the largest file.
If you use i32, it looks like you care. Without studying the code, I can't be sure that it could be changed to i16 or i64 without breaking something.
Usually, I just want the widest type that is efficient on the machine, and I don't want it to have an inappropriate name. I don't care about the wasted space, because it only matters in large arrays, and often not even then.
In Rust, that's not really the case. `i32` is the go-to integer type.
`isize` on the other hand would look really weird in code — it's an almost unused integer type. I also prefer having integers that don't depend on the machine I'm running them on.
And which machine is that? The only computers that I can think of with only 64-bit integers are the old Cray vector supercomputers, and they used word addressing to begin with.
It will likely be common in another 25 to 30 years, as 32 bit systems fade into the past.
Therefore, declaring that int32 is the go to integer type is myopic.
Forty years ago, a program like this could be run on a 16 bit machine (e.g. MS-DOS box):
#include <stdio.h>
int main(int argc, char **argv)
{
while (argc-- > 0)
puts(*argv++);
return 0;
}
int was 16 bits. That was fine; you would never pass anywhere near 32000 arguments to a program.
Today, that same program does the same thing on a modern machine with a wider int.
Good thing that some int16 had not been declared the go to integer type.
Rust's integer types are deliberately designed (by people who know better) in order to be appealing to people who know shit all about portability and whose brains cannot handle reasoning about types with a bit of uncertainty.
Sorry, but I fail to see where the problem is. Any general purpose ISA designed in the past 40 years can handle 8/16/32 bit integers just fine regardless of the register size. That includes the 64-bit x86-64 or ARM64 from which you are typing.
The are a few historical architectures that couldn't handle smaller integers, like the first generation Alpha, but:
a) those are long dead.
b) hardware engineers learnt from their mistake and no modern general purpose architecture has repeated it (specialized architectures like DSP and GPU are another story though).
c) worst case scenario, you can simulate it in software.
Please, I have no patience for the purposefully obtuse. It's clear I was referring to other languages there.
Which, you failed to address. Probably because it was difficult, so you figured if you just said "I'm right" and elaborated nothing nobody would notice. Sorry, that doesn't work on people who are awake.
As I've said, you can argue that C++ is weakly typed but you MUST also address languages like C# and Java to make that argument. You haven't, so nobody will believe you when you say C++ is weakly typed.
