The latest nixers newsletter linked to an article with the same title as this thread.

After reading it, I'm prompted to ask: is the trend to rewrite so many utilities in Rust or Go an example of minimalism, or of bloat?

I'm tempted to say the latter, because I don't care for the toolchains they bring along. Any time I look at the git repository for some tempting project and see references to cargo, I say no thank you. I dislike that almost as much as cmake.

(It's taken me years to grudgingly accept autotools. But it's still a strike against any program that uses them.)

And maybe I'm misunderstanding or overreacting but golang apparently has a worrisome style of pulling dependencies out of the cloud. Um, no, I'm not comfortable with that either.

What do my fellow nixers think? Am I just a crotchety old C programmer who likes simple makefiles? and everything statically linked and preferably less than a megabyte after stripping (less than 500K even better)?

That particular article for me sat in between satire and seriousness, but it was still a fun read.

(21-02-2025, 04:41 PM)ckester Wrote: Is the trend to rewrite so many utilities ... minimalism, or of bloat?

As with most things, I guess it depends what people mean by minimalism and bloat. For me minimalism is that when I look at a process tree I'm able to know everything that's in there. But it also means for me not having to pass through hoops and juggle 5 balls to be able to get the thing running, I'd rather have a solid straightforward solution.

That also doesn't mean I dismiss trying new stuff, on the contrary. There are a few of the new utilities I enjoy very much like jq, fzf, ripgrep.

(21-02-2025, 04:41 PM)ckester Wrote: Any time I look at the git repository for some tempting project and see references to cargo, I say no thank you.

(21-02-2025, 04:41 PM)ckester Wrote: preferably less than a megabyte after stripping (less than 500K even better)?

I have a similar issue with projects that have gigantic build systems, or where the final binary is 100+MB. That's just too much of a bubble where the devs live in a world of fast fiber internet and laptops-of-the-year. That's just not the case in most places, it's hindering the adoption of such tool, and pushing these tools in a direction where only the people that can install them can actually contribute and propose ideas on how to improve them.

Is that "bloat"? I'm not sure, I think it depends how many other tools you already have on your system that depends on that build environment. But if you're compiling a single binary and it requires you to pull 1GB of dependencies and build system, I'd say in that case that size can be part of "bloat" too.

I'm also interested in other's opinions.

Most software can be compiled locally, and I usually recommend my users to build my tools themselves instead of just fetching a precompiled binary. Some of it depends on the runtime: I have been doing a lot in Common Lisp recently, and Common Lisp is not exactly lightweight when it comes to built binaries, because they contain a whole Common Lisp environment, even when compressed.

But they're still static binaries, which is good. YMMV.

An often overlooked virtue of small statically-linked binaries is that they can used in a shell pipeline or script without unacceptably degrading performance due to the time needed to load them.

Larger statically-linked binaries obviously take more time to load.

Those using shared libraries or runtime environments are even worse (unless, of course, other programs using the same libraries or environment have already been loaded into memory -- which is one of the reasons I have a longstanding complaint about what I call "vanity libraries", which their authors distribute as shared libs but which are only ever used by their own programs and almost never at the same time. I.e., they're not really "shared" at all. They're just wasting time doing the work to locate the library, load it, and resolve the references to the code therein.)

Sorry for the rant!

EDIT: yes, I know there are ways to map files into memory without actually copying the data until it's needed. But I think my point still stands, because the larger the code the more likely a cache miss is going to be. (Especially if the code is poorly organized with respect to locality.)

(21-02-2025, 04:41 PM)ckester Wrote: What do my fellow nixers think? Am I just a crotchety old C programmer who likes simple makefiles? and everything statically linked and preferably less than a megabyte after stripping (less than 500K even better)?

No I think this is essential for coreutils. As a 26 year-old C++ dev who uses a bunch of 3rd party libraries and lives in CMAKE hell, I dislike this new idea of writing coreutils in Rust and pulling 3rd party dependencies with Cargo, even though at my day job this solution solves a lot of my frustrations with corporate development.

I do think however there is some developer ergonomics that people "think" the Rust toolchain solves that we have not done a good job solving in the C++ community, and certainly not in the C community. People seem to really want "modules" see p2990r0. I have never understood this. I want the OS and/or GCC to handle C/C++ feature support with Linux package managers that append headers to /usr/include and DLLs to the correct place so that I can just do #include <newHeader>. We don't need something like PIP, NPM/JSR, or Cargo. In fact Arch Linux manages Python package installs this way with Pacman. My point being that in the Unix ecosystem we don't need this problem solved at the language level, but at the Linux distribution level. Also think of how many reports we have of malware being distributed through those services that we know of...

I think there are two main things that would improve Unix developer ergonomics in a way that would be easier to implement than Rust rewrites and would have the same effect:

1. All GNU Corutils should be formally verified for correctness with tools like Frama-C, CBMC, or Coq. Not sure which one is the best here, I just think adding one to a CI/CD pipeline would make all the people who complain about memory safety not have room to stand on.

2. We need a better pipelining scripting language compared to Bash/Sh. As a younger developer the syntax and semantics of these scripting languages seems like a hack to try and emphasize using ASCII as your form of universal data. I do think this was a good approach initially, but we need to modernize here. Windows Powershell and Nushell both pass data as binary encoded streams to other programs. This improves speed, data size, and limits escape sequence vulnerabilities. I was reading the other day about how Guido originally wanted Python to appeal to Unix hackers...Imagine if that became the default scripting shell on Unix systems. To be fair I think the ideal thing to replace Bash/Sh doesn't exist. Perl seemed like maybe the best bet for a while, but the fragmentation between Perl 5.x and Raku doesnt help create a cohesive environment that we would need. In my dream world I think something like an easier Haskell would be ideal. Functional, immutable data by default, and lazy evaluated.