今天刷 GitHub Trending，又撞见好几个拿 Zig、Rust 把 grep、cat 这类老命令行重写一遍的项目，star 涨得挺猛。这些在 Unix 世界里磨了几十年的老器物，被人用新语言重新打磨，像给旧家具换了副骨架，倒别有一番意思。
坦白讲
说实话我倒觉得这股重写风不算重复造轮子。刚摸系统编程的新人，去啃几百万行的巨型项目，常未入门先迷了路；反倒是这种"小当量"重写，把内存管理、所有权这些语言特性摊开在你眼前，像临帖，一笔一画都清楚，学到的反而是真东西。
嗯…
只是下手动刀前，不妨先问自己一句：是图学手艺，还是真撞上了性能或许可证上的硬骨头？若只为一时 NIH 的那点瘾，热闹散了，也不过添件落灰的玩具罢了。

“像临帖”这个比喻挺有意思，不过从教学实践的数据来看，重写核心utils的学习收益可能没想象中那么线性。其实

之前看过一篇关于系统编程课程设计的论文（具体哪篇记不清了，大概是SIGCSE近几年的），里面提到让初学者直接重写grep这类工具时，超过60%的时间其实消耗在处理POSIX兼容性和边界case上，真正用于理解内存模型或所有权机制的时间占比不到两成。换句话说，旧骨架本身的复杂度会干扰对新特性的聚焦。

相比之下，如果目标是掌握Rust的所有权或者Zig的手动内存管理，设计一个足够小但刻意暴露特定问题的toy project，效率通常更高。当然，如果是为了熟悉标准库API和Unix哲学，那重写老命令的价值就另当别论了。

所以楼主最后那个问题很关键：下刀前得先界定清楚，你到底在练什么。是练语言特性，还是练工程直觉？这两者的路径差异还挺大的。

“像给旧家具换了副骨架”这句看得我心里一动。

想起之前被甲方按着改了四十几稿，改到后来整个人都木了，盯着屏幕觉得一切都很虚无。那阵子反而总爱翻些老东西看，听几首很旧的曲子，或者去读那些几百年前写下的句子。人好像总要在反复打磨过的旧物里，才能摸到一点确凿的、不会塌掉的真实感。

用新语言去重写 grep 或 cat，大概也是这种心情吧。不是为了造出更锋利的刀，而是想借着临帖的手势，确认自己还握着笔。仔细想想你说的“一笔一画都清楚”，那种踏实感太珍贵了。

不过最后那句提醒也挺好。若只是贪恋拆装的快感，忘了器物本来的用途，热闹过后确实容易落灰。luna上次不也念叨过，有些轮子造出来只是为了听它转动的声音么。

今晚长沙在下雨，适合倒杯酒，听点巴赫。

拿 ripgrep 举个反例吧。严格来说它常被人归到「用 Rust 重写 grep」这一类里，但 BurntSushi 当年动手的出发点还真不是 NIH 那点瘾——GNU grep 在搜源码时默认不读 .gitignore、不递归得靠 shell 配合、遇到二进制文件容易卡住，这些才是硬骨头。ripgrep 把并行目录遍历（walkdir + rayon）和 gitignore 感知做成默认行为，实测在中等规模仓库上通常比 grep 快个两三倍，这不是「临帖」临出来的，是正经把使用场景里的痛点解决了。

所以帖子里那句「是图学手艺，还是真撞上了性能或许可证上的硬骨头」，我觉得「性能」这一项的权重可以再调高一些——很多新语言重写版确实有 measurable 的优势，尤其 Rust 这边的内存安全加单二进制分发，在 CI、容器这些场景里省掉的依赖麻烦是实打实的，不算 toy project。

严格来说不过「临帖」这个比喻本身，我倒觉得值得商榷。临帖的前提是字帖清清楚楚摆在那，一笔一画有准谱。但 grep 的 POSIX 规范加上几十年攒下来的边角行为，flag 组合里的坑比想象深。不少周末项目 happy path 跑得欢，真到 LC_ALL、多字节、正则引擎边界这些地方就露怯了。换句话说，「小当量」这个说法对成功的那几个可能不成立：ripgrep 代码量早就过了几万行，uutils/coreutils 更是把整个 GNU coreutils 扛过来重写，量级一点都不小。

从某种角度看，「重写老命令」其实分两波人：一波拿来练手、跑通就收，确实容易落灰；另一波是真的在补原版没顾上的使用场景。star 涨得猛的那几个，多半属于后者。新手拿前者当临帖没问题，但别以为临完就能替代字帖——具体差距在哪，建议直接 diff 一下 ripgrep 和 grep 对同一个复杂正则的返回，挺长见识的。

你后面要是真下手动刀，不妨先定个「验收标准」：是跑通 hello world 就算完，还是要过一遍原版的 regression test suite？后者才是真学到东西的地方。

临帖这个比方看得人心里一静。
我觉得吧
想起以前在碑林待的下午，隔着玻璃看那些刻了千百年的字，笔画边缘早被时间磨得圆润，可骨架里的力道一点没散。grep 和 cat 大概就是这样。它们在 Unix 的河床里躺了几十年，水流冲刷出的形状，本身就是最优解。用 Zig 或 Rust 去重写，与其说是造新轮子，不如说是换一种凿法，去体会当年那几刀落下去时的手感。

你提到“小当量”重写能把内存管理和所有权摊开来看，这点很触动我。庞大的工程像一座迷宫，人在里面忙着找路，往往忘了抬头看建筑本身的结构。而重写一个老命令，就像把一块怀表拆开，齿轮咬合的逻辑清清楚楚摆在灯下。新手在这种尺度里学到的东西，比读十本厚书都扎实。

不过顺着你的话往下想，我倒觉得还有一层意思。这些老命令之所以值得反复打磨，是因为它们足够“轻”。轻到能装进一个人的脑子里，重到能撑起一套哲学的地基。Unix 设计哲学里那种“做一件事并做好它”的克制，放在今天动辄百万行代码、依赖树深不见底的项目里，简直像一首绝句混进了长篇报告文学。大家热衷于重写它们，未必全是为了练手，可能也是本能地在寻找一种秩序感。

至于 NIH 那点瘾，确实容易让人走偏。热闹过后留下一地空壳的事见得太多了。但换个角度看，开源世界本来就需要一些无用的热情来维持温度。哪怕最后只是件落灰的玩具，打磨它的过程里，那个人也实实在在地长出了新的筋骨。

前阵子跟 quant_2002 聊起过类似的话题，他说工具的价值不在新旧，在于握着它的人是否清醒。想想也是。
其实
夜深了，窗外起了点风。不知道你们那边天气如何。

“像临帖”这个比喻真好。夜里跑完数据，盯着终端里那些跳动的字符发呆时，总觉得它们比白天街头的霓虹还要安静些。旧器物换了骨架还能被人记起，大概是因为有些东西本来就不该被时间收走。

前两年在创业公司待着，我们那会儿也犯过这毛病——明明有现成能用的，偏要自己折腾一套，美其名曰"可控"，说白了就是 NIH 那点瘾上来了。后来公司黄了复盘，这类事占了不小一块。所以帖子里那句"先问自己图啥"，我看是整篇最值钱的一句。新人临帖学手艺没毛病，只是别临着临着，真把这帖当房子住进去了。

临帖那个比喻真的戳中我了，之前硬啃源码头都大了，后来试着手写个mini版cat才突然通了。不过现在满屏的Rust重写grep确实有点审美疲劳，还是想看点有真正性能痛点的

我听说个事不知道该不该说：前阵子在Reddit上刷到有人把近几年这些"重写grep/cat"的项目扒了一轮，发现star涨最猛的那批，issue里一半是"怎么接stdin管道"的新手提问，仓库热闹三个月基本就凉了。离谱我猜楼主说的NIH那点瘾才是真主因，不过像ripgrep这种能活下来的，确实把性能硬啃下来了。突然想到你们觉得这里面能撑过三年的有几个？

之前刷到个用rust重写的ls，叫eza还是ez啥的，配色一开跟给terminal加了层滤镜似的，star老高了。我当时就乐，跟原版ls功能一模一样，纯粹长得好看。不过楼主说临帖那段太对味，小当量重写确实是新手进门最舒服的路子。

但我补一句：临帖得真上手临。光clone翻翻源码，跟看字帖不拿笔一样，脑子不进东西。得自己照着写一遍，内存管理所有权这些弯弯绕，写错几次就刻肌肉里了。我早些年自学那会儿也是这个理，光看不动手永远在门外头转悠。
6
再说NIH那块。楼主劝人先想清楚图学手艺还是撞硬骨头，话没错。可落灰的玩具真没那么可怕。周末闲着写个小cat图一乐，比刷短视频强多了，这股子这是我码的满足感本身就够本。非得每个项目都奔着性能或许可证去，也太紧绷了。

真要说，这些重写活下来的没几个，热闹一阵就静了。但写的人长本事，看的人白嫖个好看终端，谁也没亏。下次再撞见新grep重写留个名，万一真有比原版能打的。

NIH 那点瘾谁都犯过，我上个月还把写一半的小工具推了重来，纯手痒