是的，因为Ant自2000年起就存在，Maven自2004年起就存在，而MSBuild自2003年起就存在。在中央包管理成为常规做法之前，我们通常会将库（jars和dlls）直接存储在源代码控制中的某个libs文件夹里。即使有了中央包管理，当企业软件做得正确时，不会在每次构建时都调用互联网，而是有由法务和IT部门维护的内部仓库，只有这些包可以在项目中使用。因此，工具已经存在了20多年，没有人会在玩客户的钱时进行YOLO项目管理。至于“...最新版本的SDKs...”，这是在转移目标，没有提到这一点，> Go是唯一一种我时隔10年后回来处理非琐碎源代码时，没有遇到任何构建和运行问题的语言。仅此一点，就足以让我忽略它的怪异之处。
源讨论Go 1.25 发布说明原帖 121 条评论 · 导入时统计好的，C++ 是可信的，但你真的能构建一个超过 20 年没有修改过代码或构建过程的 Java / .NET 项目（同时还要使用最新版本的 SDK）吗？ 我想你可以通过一些努力让项目编译（可能最多需要一周的时间），但它们不会是“解压旧的存档并执行 ./build.bat”那样简单。
完整原文把你的经验，加入这段讨论。
这些都是合理的，但是： > 关于“...最新版本的SDKs...”，这是在转移目标，[...]上并没有提到这一点。 我认为这应该是隐含的，因为多年来工具和库的破坏时有发生，有时你无法让旧的SDK在最新的Windows / macOS上运行。如果语言和Ant/Maven能够如此向后兼容，那其实已经很不错了！ 我不得不将一个.NET Framework 4.7的项目迁移到.NET Standard 2.0，这并不轻松（尽管升级到之后的每个新.NET版本到目前为止都很简单）。我们花了几个星期，尽管我们依赖项很少，因为我们对这方面很谨慎。
完整原文Ant和Maven已经存在很长时间了，但对我来说，它们并没有阻止Java（以及其他JVM语言）项目在构建过程中出现严重的退化。 例如，我曾参与一个项目，某天突然无法用Maven构建了，而没有任何对JVM版本、任何依赖项或Maven版本的更改。过了一段时间后，我放弃了尝试找出原因，因为同样的项目可以用Gradle构建！ 旧版的Scala项目在构建时非常麻烦，因为Typesafe仓库停止接受普通的HTTP连接，需要对sbt进行难以理解的配置更改。我在Go的世界里从未遇到过这样的问题。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。