观点：Go 尚未准备好用于企业系统，原因在这里译注：发表这篇文章

译注：发表这篇文章，不代表我认同作者的观点。大家都知道，在国内， Go 已经被很多大厂使用，早就可以用于企业系统。
对一门语言的爱，可以接受任何不同的观点，真理总是越辩越明，相信有不同的声音， Go 也会越来越好。欢迎大家留言发表你的看法。
介绍企业应用程序是一个寿命长、可靠的系统，具有多年的持久数据。如今， Golang 的世界并没有提供以企业系统构建方式构建系统的可能性。
文章插图
Martin Fowler 的“企业应用程序”
Golang 的发展文化让我们考虑几个问题，如错误处理不当、手动组合的 SQL 查询和面向轮子开发。
错误处理不当Golang 在错误处理方面提供了更多的自由。由于开发人员方面缺乏责任，这通常会导致应用程序中的错误处理不当。
最常见的情况与 sql 查询的执行有关：
defer rows.Close() // omitted errors from sql driver没有明确的方法来处理此返回的错误。实际上，该语言提供了捕获错误的特定方法：
result, err := foo()该错误是一个典型的返回值，可以通过各种方式忽略：
defer rows.Close() // omitted errors from sql driverdefer body.Close() // omitted IO errorsresult, _ := foo() // omitted errors from foo function
文章插图
【观点：Go 尚未准备好用于企业系统，原因在这里】sketch: Now you come to Me and you say “Don Gopher, handle Me.” But you don’t ask with respect. you don’t offer friendship.
此外，它会导致应用程序在 panic 函数调用后立即崩溃的风险增加，并且通常会降低可靠性。
根据 M.Nygard 的 “Release it!” ，可靠的系统必须处理每个不重要的错误而不会崩溃。没有权衡。
作为解决方案，我们可以使用其他语言的 try/catch/finally 结构添加可靠的机制。此外，还需要消除 panic 函数。当然，这将是一种较慢的方法，但更可靠。
手动编写 SQL 查询语句Golang 中处理数据库查询的典型方法是手动编写查询。如果 SQL 查询被手工编写的，那么数据库集成将是一个瓶颈。并非所有开发人员都擅长 SQL 和使用数据库。诸如 Hibernate（Java）和 Entity Framework（.NET）之类的功能齐全的 ORM 生成的典型查询已开放，用于数据库和缓存数据优化。这是根据 ‘Release it’ 来编写可靠的应用程序的最有效方法之一。
有些库将来可能是功能齐全的ORM（例如 GORM 和 XORM）。我相信，与手工编写的 SQL 查询相比，它们将来会更受欢迎。
重新发明轮子通常， Golang 开发人员都在选择重新发明轮子。轮子无处不在：task scheduler ，迁移工具， logger ， worker pool ，十进制数字的库，授权库和其他工具。
它们没有经过良好的测试，没有良好的文档，在生产中使用不足。风险太高，不能在企业应用程序中使用它们。
为了减少使用风险代码的可能性，检查是否有可用的解决方案。例如可以查看：。
生态系统Go 世界的生态系统包括 Consul, Kubernetes, Zipkin 和 Tr?fik 等。它是一个非常年轻且发展迅速的技术栈，没有公认的使用标准。
Golang 生态系统中没有任何工具可以帮助建立可靠的企业系统。
考虑到以上所有情况，我们需要非常谨慎地将第三方中间件集成到基础架构中，公司必须有足够的专业知识支持该过程。否则，它将成为具有不同技术的生产环境中的雷区。好消息是，市场有很多管理解决方案，以最大限度地降低风险。不幸的是，它很贵。