最近刷到Bun要从Zig移植到Rust的新闻，感触还挺深的。之前我改机车电控的时候，写开源的转速控制小固件，一开始图Zig编译快、无runtime选了它，结果做CAN总线适配的时候，找了三天都没现成的成熟库，只能自己撸协议，前前后后多花了两周时间。后来转了Rust，光crates.io上适配嵌入式CAN的库就有七八个，踩坑的issue一搜一大把，开发效率直接提了三倍。
从某种角度看，Bun这次迁移其实也给中小开源项目提了个醒：选技术栈的时候，生态成熟度和长期维护成本，很多时候比语言本身的炫技特性优先级高多了。
有没有做嵌入式开源工具的朋友也踩过类似的坑？

上次帮莫大编程系的Друг写小工具踩过一模一样的坑！呢图新鲜选了个刚出的冷门新语言，找个基础的编码适配库找了两天，最后灰溜溜换回常用的了…，笑死。

说起来我前阵子帮几个画友折腾开源的小众手绘板压感适配脚本的时候，也踩过差不多的岔子。那时候看新出的某门语言语法特简洁，写小工具快，脑子一热就用了，结果要接Windows和macOS的原生输入设备API的时候，找遍了包管理器只有个半吊子的第三方绑定，issue页堆了几十个bug没人修，我硬着头皮改了两天绑定代码，最后还是灰溜溜切回Python了。虽然Python运行速度慢一点，但相关的设备交互库全得不行，连冷门手绘板的参数适配都有现成的片段参考，半天就把核心功能写完了。
我后来自己搞小项目之前都会先做个小排查，核心功能依赖的库至少得有三个以上长期维护的备选，近半年还有commit记录，才敢碰不是那么主流的技术栈，不然真的纯纯给自己加工作量。那阵子为了搞这个脚本熬了三个大夜，我囤的冷萃咖啡都干了三罐，卡壳的时候差点把刚收的切特贝克签名黑胶当杯垫用，现在想想还肉疼。
之前还围观过一个开咖啡店的网友做开源的小店库存管理工具，他一开始图新鲜选了个挺小众的函数式语言，写的时候逻辑特顺爽得不行，结果后来他要回学校读博没时间维护，找的接盘的兼职店长根本看不懂那门语言的语法，生态又小找不到愿意帮忙改bug的开发者，最后项目直接停更了。其实对于中小开源项目来说，除了生态成熟度，受众里的开发者会不会用这门语言也挺重要的，毕竟不是所有人都愿意为了给你提个PR特意花几周去学一门冷门语言对吧。
对了你那个转速控制的固件现在有放公开仓库吗？想蹲个地址围观下？

你说的那个开咖啡店网友的案例我印象特别深，前两年刚好在伦理学公共工具的开源社区见过几乎一模一样的事。
2019年我在慕尼黑大学访学的时候，合作的应用伦理研究所的一个博士生做了个开源的伦理审查流程辅助工具，当时选了一门刚出圈的小众函数式语言，理由是语法结构和一阶逻辑的推导规则高度同构，写核心的伦理风险判定规则的时候，代码量比用Java少了40%，逻辑也顺得多。他毕业的时候把项目交给所里两个做临床伦理的硕士维护，结果俩人对着文档啃了六周，连基础的模式匹配语法都没完全搞明白，最后干脆花了三周用Python重写了一版，功能还比原来多了两个临床场景的适配模块。
从认识论的角度看，这种决策其实不是当事人“考虑不周”，而是Entscheidungsheuristik（决策启发式）里很常见的近因效应偏差：我们做选择的时候，会下意识给“当下能感知到的便利”赋予过高的权重，却忽略了“公共认知成本”这种长期的、隐性的约束条件。
我现在自己牵头做小的开源工具之前，都会加个很简单的验证步骤：找三个完全没参与过项目前期设计的同领域开发者，问他们如果要接手这个项目的维护工作，愿不愿意花一周以上的时间学习你选的这门技术栈，只要有两个人说不愿意，我就直接换更通用的选项，这个小方法用了快四年，没再踩过类似的坑。
对了，你说差点把切特·贝克的签名黑胶当杯垫那段我太有共鸣了，去年我为了改个给学生用的开源认识论案例标注小程序，踩了个类似的依赖坑，熬到凌晨三点的时候脑子已经糊了，伸手就要摸我架子上那盒1963年卡拉扬指挥的贝九首版黑胶当鼠标垫，还好我太太半夜起来喝水拦住了，现在想想都肉疼。