为什么人们涌向 Golang？而有人又在提倡 Rust？
是什么阻止了 Kotlin 成为后端的首选语言？
您可以查看 Kotlin 的 reddit 社区成员数与 Golang 成员数。这是怎么回事？
以下是reddit网友讨论的原因：
1、Go 提供了很多人想要的东西，比如快速编译时间、不需要在服务器上安装任何东西的静态编译二进制文件，以及没有“遗留”负担的生态系统。
Kotlin 很棒，但它是一个更好的 Java，同时，它并没有真正突出不同的东西。我认为它比许多已经存在的东西做得更好，但它并没有带来每个人都会蜂拥而至的新哲学。
在某种程度上，Go 带来了一种新的哲学：没有继承，没有令人沮丧的“魔法”（很多 JVM 生态系统通常通过反射和运行时代码生成来做相当多的魔法）等等。
Go 告诉它的用户“这是真正的方法”。他们告诉用户，他们没有在语言中加入任何不必要的东西，它拥有你需要的一切——这个信息来自备受尊敬的人，并得到了有史以来最受尊敬的工程文化之一的支持。
Go 已经变得非常重要，远远超出了后端 Web 开发空间。它已经成为公司制作工具生态系统的重要组成部分的语言——从 Kubernetes 到 Docker 再到 Vitess。
Go 超过 11 年的良好并发性与 Kotlin 不到 5 年的良好并发性将意味着 Go 将更具影响力。
2、大多数产品团队要从 Loom 中获利还需要一段时间。首先，您需要将依赖关系图中的框架和库迁移到 JDK 21。
在那之前，您有时间说服您的管理层至少升级到 JDK 17，这样您至少可以升级到 Spring 6 和 Spring Boot 3，以免他们更愿意为扩展支持 SLA 付费。我相信大多数企业 Javaland 确实如此。
3、Kotlin文档很差，他们转向新事物而不太关心向后兼容性。GWT 和 Angular 之类的东西就是例子，还有许多鲜为人知的库。
4、我观察到 Go 的大规模采用是由向云的过渡、适当低开销的 Go 运行时足迹和微服务推销推动的。它已经持续了十年，但最近一直在加速。
我认为这不能归结为 Go 的并发模型。Node 和 .NET 为您提供另外一种异步，Node甚至是单线程的。
我几乎没有遇到过任何 Go 营销，这与过度推广 Rust 形成鲜明对比。.NET 和 C# 的市场份额很大，尽管是在有用的价值主张方面——这与 Rust 狂热的重写世界相反。
我认为 Cloud 是 Go 被采用的主要驱动力。
5、由于我在 JetBrains 平台上开发插件，所以我只想表达一个意见。JB 正在减慢将核心代码库转换为 Kotlin 的速度，因为这里有一个大坑。
我发现阅读协程Coroutines-filled 或扩展Coroutines-filled 比 Java 难得多。每个源文件上的多个类和顶级函数也无济于事。再加上调试需要更多时间，你基本上不得不在任何地方介入。
我的结论是，一种富有表现力的语言对于编写代码的人来说很有趣，但对于最终维护它的人来说却是一个巨大的 负担。
为了更有效地调试协程，需要逐步执行代码并在任何地方都要添加日志语句，就像 1999 年一样。
更不用说互操作性了。
Kotlin 被宣传为可与 Java 互操作，但一旦您开始使用协程，它就会消失。您需要在 Kotlin 端有一个兼容层，因为所有方法都经过检测以接收额外的协程上下文。
6、与 Kotlin 相比，Golang 和 Rust 仍然很小。Kotlin 成功地用于世界各地的许多服务器端编码。已经很成功了。
7、在过去的 10 年里，我曾在许多公司担任顾问。Go 是获得大量流量的后端新代码的默认选择。不是每个人都选择使用它，但它绝对是最常见的选择并且总是在对话中。Kotlin 很少被提及。
这证明了 Go 的运行时性能，尤其是在延迟和内存占用方面，尽管如此，人们还是很乐意使用这种糟糕的语言。
8、我喜欢 Go 语言。摆脱 Java/C# 过时的 OOP。交换错误代码的异常。添加很棒的虚拟线程（goroutines）。
至于性能+延迟，JVM 和 Golang 是有竞争力的。
Go 在构建 + 依赖 + 模块简单性方面表现出色。
Kotlin 擅长原生 Android 支持 + 多平台 GUI 框架。服务器端，这很好，但我想大多数开发人员会更喜欢 Go。
9、Go 确实不亚于 Java 的面向对象。他们只是将对象命名为结构。
Kotlin 和 Java 有一些非常好的 M:N 多线程库，比 Go 的更灵活。这在很大程度上要归功于 Java 和 jvm 并没有故意限制它的发展方式。Go 的可扩展性不是很好。
Go 的模块简单性对于简单的项目来说很好，但对于本质上复杂的项目来说就很糟糕。Go 不太擅长在不变得疯狂的情况下管理复杂的业务逻辑。Kotlin 擅长简单和复杂的项目。
Go 错误处理起来非常麻烦，因为它们没有堆栈跟踪。您基本上需要手动或通过使用库为自己制作堆栈跟踪，否则调试会非常痛苦。在两个非常真实的代码库中，我看到人们在写入数据库后不小心没有检查错误，结果 prod 数据库悄无声息地填满了错误数据，结果没有任何日志表明发生了什么。除非有例外，否则不会发生这种情况。
Go 是一种糟糕的语言，具有出色的运行时和非常好的 M:N 线程模型。
10、Kotlin/JVM 在一个地方处于巨大的劣势，作为一种服务运行。冷启动在 AWS Lambda 等上是可怕的。
虽然GraalVM 可以提供帮助，但是你需要支持你自己的层。
Go 是原生的，冷启动速度快一个数量级，并且不需要 JIT 编译器在多次调用后启动以获得良好的性能。
尽管 Kotlin 是一种更好、更安全的语言，但如果我正在处理一个具有无服务器函数后端的项目，它每次都是 Go。
11、我认为有多种原因导致 Kotlin 在服务器端的采用速度似乎很慢。其中一些可能是“JVM 很慢”的误解，再加上 Go 和 Rust 都很快的营销，这种误解不会消失。他们确实是，但也可能有其他一些原因。
Go 的语法更简单，而且它几乎似乎是专门为服务器设计的——生成 10,000 个绿色线程的摩擦非常非常小。Rust 似乎是为那些想要大量控制并从代码中榨取最后一点性能的人而设计的。在任何一个中编写 GUI 都是痛苦的 IMO 教训。两者都编译为裸机并具有胖二进制文件这一事实意味着操作方面更容易，并且无需管理/更新 JVM 本身。
老实说，我认为 Kotlin 真正出色的几个地方之一是使用 JavaFX 进行富客户端编码。我还在学习它，但我真的很喜欢它。当然胜过 Electron 和 JS 以及当时的框架。