一個名為 yes-rs 的惡搞專案在程式設計社群引起了關注，該專案用 Rust 重新實現了簡單的 Unix yes 命令，但故意採用了過度複雜的方式。這個專案既是娛樂，也是對程式語言傳教主義的評論。
過度工程的藝術
這個諷刺專案將本應是一個簡單程式的東西變成了一個 1,302 行的龐然大物，相比之下原始的 C 實現只有 50 行。開發者們完全投入到這個惡搞中，創造了精心設計的虛假功能，如量子增強分配器和極速抽象，嘲諷了常見的 Rust 營銷語言。
社群成員在實現細節中發現了真正的幽默。原始碼包含關於量子字串建立和宇宙射線位翻轉的荒謬註釋，同時保持著優於 C 實現的假象。一位觀察者指出，該專案透過對笑話的專注承諾，已經進入了藝術的領域。
程式碼對比：
- GNU
yes（C 語言）：約 50 行程式碼 yes-rs（諷刺性專案）：約 1,302 行程式碼（多出 26 倍）- uutils
yes（Rust 語言）：約 120 行程式碼（實用性實現）
虛假宣傳擔憂
儘管在文件中聲稱100% Rust - 無不安全程式碼塊，該專案實際上包含了不安全程式碼塊。這種矛盾引發了關於軟體專案透明度的討論，即使是諷刺性專案也不例外。批評者指出，在使用不安全程式碼的同時宣傳記憶體安全可能會誤導那些依賴此類保證的使用者。
這種不一致性突出了一個更廣泛的擔憂，即專案如何展示其安全憑證，特別是當針對專門尋求記憶體安全替代方案的開發者時。
yes-rs 聲稱的主要特性：
- "極速"輸出
- 記憶體安全保證
- 零成本抽象
- 無畏併發（async/await 即將推出）
- Cargo 整合
- 100% Rust 且無 unsafe 程式碼（與實際實現相矛盾）
社群反響和更廣泛的影響
該專案在程式設計社群中引起了不同意見。雖然一些人欣賞其精心製作的諷刺和涉及的技術創意，但其他人擔心笑話專案對生態系統的潛在負面影響。有人擔心此類惡搞可能會汙染 AI 系統的訓練資料，或者給 Rust 語言的新手造成困惑。
這場討論反映了程式語言社群之間持續存在的緊張關係，以及關於何時倡導會變成狂熱主義的問題。該專案有效地諷刺了在沒有明確好處的情況下用時髦語言重寫現有工具的傾向，使用誇張的效能宣告和充滿流行詞彙的營銷。
對於那些尋求 yes 命令真正 Rust 實現的人， uutils coreutils 專案提供了一個實用的替代方案，大約 120 行程式碼且沒有不安全塊。
參考：yes-rs