mort/blog_nu-posix_.json at main · anil.recoil.org/thicket-eeg

Thicket data repository for the EEG
thicket-eeg / mort / blog_nu-posix_.json
at main 16 kB view raw
 1{
 2  "id": "https://mort.io/blog/nu-posix/",
 3  "title": "Rusty Nu POSIX",
 4  "link": "https://mort.io/blog/nu-posix/",
 5  "updated": "2025-05-07T00:00:00",
 6  "published": "2025-05-07T00:00:00",
 7  "summary": "<p>A slight delay to this post, but happily I now have no more lecturing to do\nuntil 2027<a href=\"https://mort.io/blog/nu-posix/#1\">1</a> :)</p>\n<p>I switched a year or two ago to using NixOS as my daily driver following about\n15 years as an increasingly irritated MacOS user. Shortly before I had become\ninterested in Rust as a systems programming language that seemed to marry\nseveral things I like about OCaml with several other desirable things from C and\nPython.</p>\n<p>I then more recently observed something that I thought was interesting: there\nseem to be a <strong>lot</strong> of recent replacements of what were once completely\nstandard and changeless POSIX utilities. I’m thinking things like <code>grep</code>,\n<code>find</code>, <code>ls</code> and the like that I’ve been using uninterrupted, other than the\noccasional quibble over whether it was the original version or the GNU version,\nfor about 30 years. Indeed, I have already raved (slightly) about\n<a href=\"https://just.systems/\"><code>just</code></a> as a\n<a href=\"https://www.gnu.org/software/make/manual/make.html\"><code>make</code></a> replacement and its\nuse with <a href=\"https://mort.io/blog/just-ocaml/\">OCaml</a> and <a href=\"https://mort.io/blog/just-latex/\">LaTeX</a>.</p>\n<p>NixOS’ declarative configuration meant that I could actually see the list\ngrowing, all in one place – I suspect on other systems I wouldn’t have noticed\nin quite the same way because it would’ve been a much more incremental and\ndiffuse process of change without a clear record of the choices made.</p>\n<p>I thus find in my\n<a href=\"https://github.com/mor1/rc-files/blob/main/nixos/modules/home-manager/cli.nix#L44-L65\"><code>cli.nix</code></a>\nconfig that describes the CLI tools I expect, to have the following collection:</p>\n<pre><code><span>      <span>nu_posix</span> <span>=</span> <span>[</span>\n</span><span>        <span>bat</span> <span># better cat</span>\n</span><span>        <span>bottom</span> <span># btm ~ better top, htop, etc</span>\n</span><span>        <span>broot</span> <span># interactive directory navigation</span>\n</span><span>        <span>chafa</span> <span># terminal graphics viewer</span>\n</span><span>        <span>ctpv</span> <span># terminal file previewer</span>\n</span><span>        <span>cyme</span> <span># better `lsusb`</span>\n</span><span>        <span>delta</span> <span># better syntax highlighting diff</span>\n</span><span>        <span>dua</span> <span># disk usage, interactively</span>\n</span><span>        <span>eza</span> <span># improved `ls`</span>\n</span><span>        <span>fd</span> <span># `find` replacement</span>\n</span><span>        <span>fend</span> <span># better CLI calculator</span>\n</span><span>        <span>hexyl</span> <span># hex pretty printer</span>\n</span><span>        <span>htop</span> <span># graphical top</span>\n</span><span>        <span>iotop</span> <span># io top</span>\n</span><span>        <span>jujutsu</span> <span># better git</span>\n</span><span>        <span>just</span> <span># updated gnumake replacement</span>\n</span><span>        <span>procs</span> <span># better ps</span>\n</span><span>        <span>ripgrep</span> <span># rg ~ `grep` replacement</span>\n</span><span>        <span>sudo-rs</span> <span># memory-safe `sudo`</span>\n</span><span>        <span>uutils-coreutils-noprefix</span> <span># replaces GNU `coreutils`</span>\n</span><span>        <span>viddy</span> <span># better watch</span>\n</span><span>      <span>]</span><span>;</span>\n</span></code></pre>\n<p>I think that most, if not all, of these are written in Rust: that particular\nlanguage community seems to have a real enthusiasm for re-implementing\nlong-standing tools but better, and I have to say I really appreciate it! When I\nsay “better” I’m not particularly thinking of esoteric language features or\ndevelopment ideologies either. I mean better in two very particular senses:</p>\n<ol>\n<li>\n<p><strong>Usability</strong>. Many of the older tools simply did not have great user\ninterfaces and, when they were ok, they were not built using modern tooling.\nAs a result getting documentation was somewhere between good and great if\nthere was a decent <code>man</code>-page, with a range of potential switches for more\nshort form help or for cases where the <code>man</code>-page was not installed –\nwhether <code>-h</code>, <code>--help</code>, <code>-help</code>, <code>-?</code>, <code>help</code>, or something else. The\nshort-form help would, of course, be formatted in arbitrary ways.</p>\n<p>The modern Rust-y replacements tend to use\n<a href=\"https://docs.rs/clap/latest/clap/\"><code>clap</code></a> as a reasonably standard\ncommand-line parser. As a result, they are remarkably consistent in usage and\nformat, typically producing something that looks a lot like <code>man</code>-page output\nin response to their <code>-h|--help</code> switch. In a world where <code>man</code>-pages are\noften an afterthought or, even worse, replaced by <code>info</code> documentation, I\nfind this invaluable. They are also generally inclined to make greater use of\nmodern terminal environments – <a href=\"https://github.com/eza-community/eza\"><code>eza</code></a>\nas a replacement for\n<a href=\"https://www.gnu.org/software/coreutils/manual/html_node/ls-invocation.html\"><code>ls</code></a>\nis a good example of this.</p>\n</li>\n<li>\n<p><strong>Performance</strong>. Old tools were originally built for old computers in old\nlanguages (largely C) and, whether this is language ideology or just the\npracticalities of engineering long-standing widely-used codebases, tended not\nto be radically updated.</p>\n<p>Rust re-implementations, on the other hand, are from scratch – and Rust’s\nmemory model appears to make it relatively easy for them to be made\nmulti-threaded. On modern hardware this seems to make them startlingly higher\nperformance than the alternatives. Tools I particularly appreciate for this\ninclude <a href=\"https://github.com/sharkdp/fd\"><code>fd</code></a> replacing\n<a href=\"https://www.gnu.org/software/findutils/\"><code>find</code></a> and <a href=\"https://github.com/BurntSushi/ripgrep\">ripgrep,\n<code>rg</code>,</a> replacing\n<a href=\"https://www.gnu.org/software/grep/\"><code>grep</code></a>.</p>\n</li>\n</ol>\n<p>Perhaps the most immediate example of the benefits of this that I’ve experienced\nis <a href=\"https://github.com/Byron/dua-cli\"><code>dua</code></a> via <code>dua i</code>. Traditionally, when\ntrying to clean up an uncomfortably full hard disk I would’ve ended up using\nsome manual iterative application of either <code>du -hS *</code> or possibly something\nlike <code>find ... | xargs du</code>. Or possibly written a Python script to do it for me.\nAnd it would’ve taken <em>O</em>(hours) for me to find where the space was being used\nand to do something about it. And I would’ve found it tedious and deeply\nirritating.<a href=\"https://mort.io/blog/nu-posix/#2\">2</a></p>\n<p>In contrast, <code>dua i</code> gives me a TUI interface to navigate the filesystem from\nwherever I run it, the ability to cumulatively mark files and directories for\ntrashing or immediate deletion, with subdirectory space summaries – and does so\nacross ~850GB / 3 million files in about 10-15 seconds without using any form of\ncaching, database, or other such thing. As far as I can tell, simply by being\nefficient and multi-threaded.</p>\n<p>If this is the future, sign me up. (At least for the bits like this that are\ngood.)</p>\n<div>1\n<p>…assuming I get back the same courses after my sabbatical that is.</p>\n</div>\n<div>2\n<p>I’m easily irritated. What can I say.</p>\n</div>",
 8  "content": "<p>A slight delay to this post, but happily I now have no more lecturing to do\nuntil 2027<a href=\"https://mort.io/blog/nu-posix/#1\">1</a> :)</p>\n<p>I switched a year or two ago to using NixOS as my daily driver following about\n15 years as an increasingly irritated MacOS user. Shortly before I had become\ninterested in Rust as a systems programming language that seemed to marry\nseveral things I like about OCaml with several other desirable things from C and\nPython.</p>\n<p>I then more recently observed something that I thought was interesting: there\nseem to be a <strong>lot</strong> of recent replacements of what were once completely\nstandard and changeless POSIX utilities. I’m thinking things like <code>grep</code>,\n<code>find</code>, <code>ls</code> and the like that I’ve been using uninterrupted, other than the\noccasional quibble over whether it was the original version or the GNU version,\nfor about 30 years. Indeed, I have already raved (slightly) about\n<a href=\"https://just.systems/\"><code>just</code></a> as a\n<a href=\"https://www.gnu.org/software/make/manual/make.html\"><code>make</code></a> replacement and its\nuse with <a href=\"https://mort.io/blog/just-ocaml/\">OCaml</a> and <a href=\"https://mort.io/blog/just-latex/\">LaTeX</a>.</p>\n<p>NixOS’ declarative configuration meant that I could actually see the list\ngrowing, all in one place – I suspect on other systems I wouldn’t have noticed\nin quite the same way because it would’ve been a much more incremental and\ndiffuse process of change without a clear record of the choices made.</p>\n<p>I thus find in my\n<a href=\"https://github.com/mor1/rc-files/blob/main/nixos/modules/home-manager/cli.nix#L44-L65\"><code>cli.nix</code></a>\nconfig that describes the CLI tools I expect, to have the following collection:</p>\n<pre><code><span>      <span>nu_posix</span> <span>=</span> <span>[</span>\n</span><span>        <span>bat</span> <span># better cat</span>\n</span><span>        <span>bottom</span> <span># btm ~ better top, htop, etc</span>\n</span><span>        <span>broot</span> <span># interactive directory navigation</span>\n</span><span>        <span>chafa</span> <span># terminal graphics viewer</span>\n</span><span>        <span>ctpv</span> <span># terminal file previewer</span>\n</span><span>        <span>cyme</span> <span># better `lsusb`</span>\n</span><span>        <span>delta</span> <span># better syntax highlighting diff</span>\n</span><span>        <span>dua</span> <span># disk usage, interactively</span>\n</span><span>        <span>eza</span> <span># improved `ls`</span>\n</span><span>        <span>fd</span> <span># `find` replacement</span>\n</span><span>        <span>fend</span> <span># better CLI calculator</span>\n</span><span>        <span>hexyl</span> <span># hex pretty printer</span>\n</span><span>        <span>htop</span> <span># graphical top</span>\n</span><span>        <span>iotop</span> <span># io top</span>\n</span><span>        <span>jujutsu</span> <span># better git</span>\n</span><span>        <span>just</span> <span># updated gnumake replacement</span>\n</span><span>        <span>procs</span> <span># better ps</span>\n</span><span>        <span>ripgrep</span> <span># rg ~ `grep` replacement</span>\n</span><span>        <span>sudo-rs</span> <span># memory-safe `sudo`</span>\n</span><span>        <span>uutils-coreutils-noprefix</span> <span># replaces GNU `coreutils`</span>\n</span><span>        <span>viddy</span> <span># better watch</span>\n</span><span>      <span>]</span><span>;</span>\n</span></code></pre>\n<p>I think that most, if not all, of these are written in Rust: that particular\nlanguage community seems to have a real enthusiasm for re-implementing\nlong-standing tools but better, and I have to say I really appreciate it! When I\nsay “better” I’m not particularly thinking of esoteric language features or\ndevelopment ideologies either. I mean better in two very particular senses:</p>\n<ol>\n<li>\n<p><strong>Usability</strong>. Many of the older tools simply did not have great user\ninterfaces and, when they were ok, they were not built using modern tooling.\nAs a result getting documentation was somewhere between good and great if\nthere was a decent <code>man</code>-page, with a range of potential switches for more\nshort form help or for cases where the <code>man</code>-page was not installed –\nwhether <code>-h</code>, <code>--help</code>, <code>-help</code>, <code>-?</code>, <code>help</code>, or something else. The\nshort-form help would, of course, be formatted in arbitrary ways.</p>\n<p>The modern Rust-y replacements tend to use\n<a href=\"https://docs.rs/clap/latest/clap/\"><code>clap</code></a> as a reasonably standard\ncommand-line parser. As a result, they are remarkably consistent in usage and\nformat, typically producing something that looks a lot like <code>man</code>-page output\nin response to their <code>-h|--help</code> switch. In a world where <code>man</code>-pages are\noften an afterthought or, even worse, replaced by <code>info</code> documentation, I\nfind this invaluable. They are also generally inclined to make greater use of\nmodern terminal environments – <a href=\"https://github.com/eza-community/eza\"><code>eza</code></a>\nas a replacement for\n<a href=\"https://www.gnu.org/software/coreutils/manual/html_node/ls-invocation.html\"><code>ls</code></a>\nis a good example of this.</p>\n</li>\n<li>\n<p><strong>Performance</strong>. Old tools were originally built for old computers in old\nlanguages (largely C) and, whether this is language ideology or just the\npracticalities of engineering long-standing widely-used codebases, tended not\nto be radically updated.</p>\n<p>Rust re-implementations, on the other hand, are from scratch – and Rust’s\nmemory model appears to make it relatively easy for them to be made\nmulti-threaded. On modern hardware this seems to make them startlingly higher\nperformance than the alternatives. Tools I particularly appreciate for this\ninclude <a href=\"https://github.com/sharkdp/fd\"><code>fd</code></a> replacing\n<a href=\"https://www.gnu.org/software/findutils/\"><code>find</code></a> and <a href=\"https://github.com/BurntSushi/ripgrep\">ripgrep,\n<code>rg</code>,</a> replacing\n<a href=\"https://www.gnu.org/software/grep/\"><code>grep</code></a>.</p>\n</li>\n</ol>\n<p>Perhaps the most immediate example of the benefits of this that I’ve experienced\nis <a href=\"https://github.com/Byron/dua-cli\"><code>dua</code></a> via <code>dua i</code>. Traditionally, when\ntrying to clean up an uncomfortably full hard disk I would’ve ended up using\nsome manual iterative application of either <code>du -hS *</code> or possibly something\nlike <code>find ... | xargs du</code>. Or possibly written a Python script to do it for me.\nAnd it would’ve taken <em>O</em>(hours) for me to find where the space was being used\nand to do something about it. And I would’ve found it tedious and deeply\nirritating.<a href=\"https://mort.io/blog/nu-posix/#2\">2</a></p>\n<p>In contrast, <code>dua i</code> gives me a TUI interface to navigate the filesystem from\nwherever I run it, the ability to cumulatively mark files and directories for\ntrashing or immediate deletion, with subdirectory space summaries – and does so\nacross ~850GB / 3 million files in about 10-15 seconds without using any form of\ncaching, database, or other such thing. As far as I can tell, simply by being\nefficient and multi-threaded.</p>\n<p>If this is the future, sign me up. (At least for the bits like this that are\ngood.)</p>\n<div>1\n<p>…assuming I get back the same courses after my sabbatical that is.</p>\n</div>\n<div>2\n<p>I’m easily irritated. What can I say.</p>\n</div>",
 9  "content_type": "html",
10  "author": {
11    "name": "Unknown",
12    "email": null,
13    "uri": null
14  },
15  "categories": [],
16  "source": "https://mort.io/atom.xml"
17}