… 哦，所以，一点自我推广：如果你喜欢Go但对它的易用性感到沮丧，我请你尝试我开发的编程语言Oct，用于LLM编程，你可以把它看作是我为Go的Java打造的Kotlin：它使用代码生成编译器，并编译成普通的Go二进制文件，因此可以在所有Go运行的地方运行，而且还有很多额外的功能：类似Rust的穷举带标签/载荷的枚举/`match`，C#的不可变记录，用`with`更新，穷举的错误处理，简单的并行并发，xUnit.NET风格的单元测试框架，TypeScript风格的编译时约束，类似F#的SI单位系统，Go代码生成的元编程等。非常希望Hacker News上的Go专家们能来看看它，并提供一些反馈。https://github.com/yuechen-li-dev/oct
源讨论为什么Go是AI辅助软件工程的理想语言原帖 542 条评论 · 导入时统计把你的经验，加入这段讨论。
那么在主流语言方面，你认为哪种语言会是理想的呢？（至少在Oct流行之前！）也许是现代Java？……或者甚至是Zig？
完整原文> Go对于人类作者来说确实有很多问题，因为它非常冗长且有大量样板代码，这意味着对于LLM来说，这比对于人类程序员来说更不是问题。 如果文章的前提是正确的，我认为确实是这样，那么这对AI编程来说是一个相当大的缺点。前提是现在审查比编写更重要。 我个人更喜欢审查一个Ruby的一行代码，用filter_map从CSV文件中提取特定行的值，而不是40行左右的Go代码，其中许多我必须逐行检查可能的错误。
完整原文Go没有任何从C++或Java逐步迁移的方案；你是在说要从头开始重写所有这些代码库，这在工程资源有限的情况下显然是不可能的。 据我理解，Fuchsia主要用Dart做UI部分，而Go从未真正试图在这一领域竞争？我看不出有什么理由认为这是阻碍Fuchsia采用的严重瓶颈，相比起取代拥有巨大安装基础的现有操作系统显然更难这一点。
完整原文> "因为LLM不会犯人类会犯的编程错误，这证明了借用检查器存在的合理性" 必须提供引用。
完整原文我的意思是，我并不反对Go语言，但坦白说，它并不比现代Java更好。 各有优缺点，两者都可以支持原生编译的应用程序代码。有些架构在Go语言中更容易审查和编写代码，但其他架构则更适合Java更丰富的生态系统和更好的可组合性。
完整原文> 相较之下，Rust表现得更差，因为LLM不会犯人类会犯的编程错误，这证明了借用检查器存在的合理性，它只会阻碍它们，它们花更多时间与Rust的基础设施作斗争，而不是编写代码。 我发现事实正好相反：人们总是认为他们可以不用机器检查就能写出安全的并发代码，结果在很多细微的情况下完全搞错了。但问题现在更严重了，因为你甚至不是在编写代码，或者在很多情况下，根本不是在阅读代码。我更喜欢一种类型系统能帮我避免仔细检查（并且几乎总是会发现其中的问题）的并发不变量的审查负担。而且它还能告诉我更多关于代码意图的信息。
完整原文> 相较之下，Rust表现得更差，因为LLM不会犯人类会犯的编程错误，这证明了借用检查器存在的合理性，[...] 这完全是胡说八道，原谅我的粗话。来源/证明？ 相反的情况是： 我在这段时间里一直在处理一个调用C++原生/wasm编译代码的TS代码库，已经六个月了。这些代码大多是LLM编写的。 在这过去的六个月里，我们有四次使用已释放的内存和两次其他与所有权相关的错误在LLM生成的TS代码中。 而我们在另一个两个原生/wasm编译的metacrates中使用的LLM生成的Rust代码中，没有任何此类问题。 LLM在跟踪所有权方面并不比人类好太多。 特别是当资源获取和释放在代码中相距较远，或者以某种方式嵌套/堆叠/不直接的情况下。
完整原文> Go 无疑对人类作者来说有很多问题，因为它非常冗长且充满样板代码，这意味着对于 LLM 来说，这比对人类程序员来说是个更小的问题 我认为样板代码和冗长对于 LLM 来说比人类编程更是一个更大的缺点，因为上下文腐化和“中间迷失”现象对代码质量的影响非常大 看起来 LLM 从语义和语法的密度中受益
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。