有趣的是，我之前一直用Rust配合Claude，因为这个原因，而在Anthropic对Bun进行重写之前，我尝试过用Rust重写一个我之前闲置的C#项目（来自2008年的.NET 3.5），虽然不是完美的，但现在几乎完成了，主要是出于兴趣，而且我之所以这么做，是因为我意识到LLM可以用于更严肃的重构，所以我觉得可能对语言重写也有帮助。果然如此。我认为将处理文本并以Rust这样的语言进行转换的工具重写为JS项目是可行的，Go也一样，这就是为什么TypeScript正在迁移到Go。‘免费’的优化速度提升是值得的，尽管需要花费一两年时间来处理迁移，但借助LLM，似乎可以将初始工作量缩减到一周左右？太疯狂了。

> LLM降低了Rust编程的入门门槛 我认为你实际上想说的是“降低门槛”（这会让通过门槛变得更容易，而“提升门槛”会让它更难）？

> 这充分说明了这门语言的优势 内存安全只是整体安全的一小部分。如果一个LLM能正确转码，那么它也应该能输出100%正确的C代码。 另一方面，如果一个LLM不能正确转码，那么使用Rust可能只是让错误变得无声，因为语言运行时/代码生成“避免”了通常会让错误（和错误报告）变得明显的惩罚。

> 这充分说明了这门语言的优势，也说明了LLM降低了Rust编程的入门门槛。借用检查器的问题可以交给模型，你只需专注于其他编程逻辑。 我得到的相反印象是，如果他们不够自信亲手编写代码，我认为这说明这门语言要么难以编写，要么难以阅读，或者两者都有。通过委托给LLM，并没有“降低入门门槛”，只是节省了打字时间（就像它被翻译成C或Kotlin时一样）。如果他们真的决定“专注于其他编程逻辑”，而不仅仅是随意编写代码，他们仍然需要能够理解和推理代码。

仅仅因为某样东西是用Rust写的，并不意味着它是好的Rust代码。 我注意到，总体而言，LLM倾向于通过把问题掩盖起来（比如添加一个强制转换）或写一个超级局部的“修复”来解决问题，而不是花时间去理解更深层次的问题或结构。 在Rust中，当你陷入复杂的借用检查问题时，Rust社区会告诉你这是件好事（tm），因为它迫使你思考代码的更高层次架构。而LLM则可能反复尝试“修复”这个问题，然后只是扔进一个Refcell（或其他变通方法），看到它能编译，就认为问题解决了。 Refcell将借用检查移到了运行时，这意味着代码会通过编译，但如果同一对象同时从两个不同地方被访问，它会在运行时崩溃。在大多数“正常”的编程语言中…