typescript vs go vs rust
typescript 后端选型：
Express &Typescript &trpc 广泛使用，灵活，快速，稳定
Nestjs 企业级，标准化，像java ，依赖注入，
Hono , web standards framework. Support for any JavaScript runtime.
思考：
最近我和几个用Go和Java/Kotlin写后端的开发者聊过。他们说TypeScript差远了，Go和Java/Kotlin才是真正的现代后端语言。但是当我问到具体原因时，他们却很难说出什么具体的来。他们声称，例如，这些语言的工具比TypeScript要好。
我过去在前端编程（React）中大量使用过TypeScript，并没有用它做过很多后端开发。但我认为TypeScript 是一门强大的语言，它非常灵活，而且有类型系统。我对后端工具不太熟悉，所以他们在这点上可能是对的。
但是当涉及到微服务时，我看不出使用Go/Kotlin比TypeScript有什么优势。你只需要用一个Docker容器，做一个Express的endpoint，就完事了。
另外，我认为在后端使用TypeScript的优势在于，你可以用同一种语言做前后端，这对小型公司/初创公司特别有用，因为它们通常拥有更多全栈开发者，而不是严格区分前后端开发者。
TypeScript本身比前端更适合后端领域，因为你的类型更多的是围绕领域逻辑而不是DOM。所以从这个意义上说，它真的很好。
很多人吹捧Go，我在一些大量使用Go的地方工作过，但我个人始终无法接受它在美学上的丑陋。我几乎在各个方面都更喜欢Rust。
这里有很多关于性能的讨论，但是取决于你的领域，你可能不会注意到区别。如果你使用的是现代基础设施，例如无服务器架构，那么TypeScript在很多用例中实际上性能更好——例如HTTP API。如果你受限于更传统的选项，例如Docker，那么TypeScript可能不是最佳选择。
如果你已经熟练掌握了TS和TS工具，那么在后端使用它完全没问题。但我个人讨厌Express和其他Node生态系统的框架，所以我需要补充一点，如果我不能使用Lambda/无服务器生态系统，我会避免使用TS。
TS比Java/C#最大的优势在于它默认情况下不是面向对象的语言。当然，你可以将TS与OOP一起使用，但是能够自由地编写操作数据的自由函数非常令人解放。我不再想把所有东西都塞进一个类里了。
还有其他优点。例如，我们运行微服务和微前端。对于使用全栈TypeScript的团队来说，这意味着他们的服务可以是一个小型单体仓库，其后端和前端在同一个仓库中共享API契约类型。我想，那些在后端使用C#的团队必须做其他事情，例如契约测试。
然后还有测试框架、ESLint、IDE配置等等。能够停留在相同的工具集中是很好的。
老实说，对于任何需要企业级规模并需要能够快速构建和维护的项目，TS都是我的后端默认选项。但如果我做的是计算密集型的工作，我会选择Rust——这几乎总是后台作业，所以我的API几乎总是用TS。
是的！在无服务器环境中使用 TS 太棒了，fp-ts TaskEither 真的非常适合那些可能以奇奇怪怪的方式失败的异步 API。
对我来说，关键在于编译时间和运行时间。我们必须记住，JS严格来说不是强类型语言，所以在你的程序编译掉那些类型之后，如果出现问题，你该怎么办？我更倾向于对后端密集型的东西，比如支付系统，使用强类型语言。
对我来说，另一个重要的事情是企业级应用的包，特别是像支付系统这样高风险的东西。我更喜欢那些内置库更多，而且经过多年验证的库，而不是一些JS开源库。尤其是在考虑安全性的情况下。JS的依赖性简直是地狱。