切换到 Go 可以提高生产力?
我最近换了一份工作，从 Java Spring Boot 微服务过渡到了单体 Go 应用程序，对我来说，工作效率的提高令人难以置信。
我们最喜欢 Go 应用程序的一点是，后台不再有魔法发生，不再有注解的奇怪交互，也不再有迁移的噩梦。
虽然我很清楚自己更喜欢 Go 后端，但我目前的经验主要是为现有功能添加增量。我很少需要引入新的数据库表、服务等。这让我不禁要问，Go 是否能为初创公司或业余项目的小型应用程序提供同样的生产力提升？
Spring Boot、Ruby on Rails 和 Django 等大型框架提供的 "开箱即用的功能 "是否超过 Go 后端的优势？
例如，在内置 ORM、安全性和代码生成方面。
使用这些框架从 0 到 50 的过程是否更快？更确切地说，从长远来看，使用这些框架从 0 到 50 更快是否值得，即使这样做会给系统带来 "魔力"？
#####################################################################
直到 3 年前，我还在使用 Spring Boot/Kotlin 后端，后来转到了一个使用 Kotlin 而不使用任何框架的团队。我认为 "安全性 "不一定是继续使用 Spring Boot 的理由。我都数不清有多少次出现 Spring 漏洞，其他团队争先恐后地为其打补丁，而我们还在继续冲刺阶段的计划开发工作。
除此之外，我认为从 Spring Boot 转向 "无框架 "模式有利有弊。
优点：
- 如你所说，没有 "魔法"--当你不深入 Spring 源代码的 20 个文件时，调试问题要容易得多
- 你能更好地了解代码在做什么，这同样有助于排除故障，但也不会让你对代码的性能、效率和安全性产生错误的认识。您编写了这些代码，应该对您为了可读性/可维护性/安全性而牺牲性能的地方有一个大致的了解，反之亦然。
- 你将成为一名更好的开发人员，因为你能更好地理解这些库是如何工作的，这些库通过优雅的应用程序接口抽象了大量底层功能。
- 你的传递依赖关系树（应该）更小。这就意味着你不太可能让一些随机库（你甚至并不真正需要它）标示出安全漏洞。我记得在使用 Spring 时曾多次遇到过这种情况。
这并不是说违背框架就没有问题：
- 招聘和录用初级人才要困难得多。当你编写很多框架通常会处理的东西时，它们很可能是定制的，或者是新员工从未见过的不同模式。雇用初级人才并非不可能--你总是可以雇用那些有学习能力的人，但在他们真正做出贡献之前，你需要为他们准备更长的提升时间。
- 构建自己的解决方案需要更多时间。你需要说服你的产品和工程领导层，让他们相信推迟交付 x/y/z 是值得的。
- 因此^，你的团队通常需要更多的工程人才。根据预算，这可能是可行的，也可能是不可行的。
根据我的个人经验，在企业级开发时，如果有足够的工程人才和产品/领导层的支持，我总是会选择避免使用像 Spring 这样的大框架。与使用 Spring 时相比，我在过去几年中在这种堆栈中工作得更开心。
不过，我并没有完全回避 Spring 或类似 Spring 的解决方案。我家里总是有很多使用各种语言的个人代码项目，我几乎没有时间真正投入到这些项目中。在这种情况下，我通常会选择一个已经为我构建了大部分内容的框架。
这里确实没有放之四海而皆准的解决方案。这完全取决于你的可用资源和你的领导层是否愿意接受。
####################################################
很高兴看到更多的人感受到专业使用 Go 工作所带来的新鲜空气！我确实感觉工作效率更高了，并且随着时间的推移，代码变得更容易理解和维护。
#################################################
对于（通常是特殊用途的）服务器应用程序来说，Go 建立静态二进制文件的方法往往是一大优势。它让操作变得更容易。
但多年前，我也用 Java（普通的 Java）+ gcj 做过同样的事情：
这是一个针对特定客户的中间件工具箱。
背景：我的客户定制安装了大量业务应用程序（Zimbra 群件、Redmine、Plone 等），并将其集成到客户的基础设施中。由于我们已经厌倦了定制所有单独的应用程序，我们决定定义标准化接口，在应用程序中实现这些接口，并将所有客户特定的逻辑移到一些小型中间件中。
印度的程序猿想要 Java，所以我给了他们 Java。我们的首席操作员想要一个简单的可执行二进制文件（而不是什么 jee monster）。于是我给了他（单一二进制文件，静态链接）。我花了一两天时间做了一些原型（基本的 HTTP/REST 服务器和一些假处理程序）。
有趣的是：当印度团队拿到它时，他们很容易就完成了构建（我已经教过他们使用 makefile 进行 Zimbra 扩展），但不知道如何部署/运行它--他们急切地寻找 .jar 文件，却不知道如何处理可执行文件：P
########################################################
在我看来，"无框架 "在涉及 hello world 应用程序以上的项目中是不存在的。你很快就会根据自己的设计选择构建自己的框架，而这些选择与主流框架相比可能几乎没有任何好处，而且你的框架很可能会有较差的文档，因此入职培训将更加费时费力。
因此，根据我的经验，每个项目都有一个 "框架"，问题在于你是要投入时间来构建和维护自己的框架，还是要投入十分之一的时间来学习如何使用主流框架。
我的经历与你正好相反。自从改用 golang 后，我感觉自己就像在泥潭里游泳。要写的代码明显更多，犯错的机会也更多，与其他语言相比，golang 的生态系统非常糟糕，只有极少数像样的库，而且这些库似乎都被抛弃了。该语言自带的最佳实践似乎与其他语言中的许多最佳实践背道而驰，或者至少会被人诟病。总体感觉就像在 2006 年使用 PHP，但我还没有放弃它。