其实大厂背书不总是什么很好的点，有时候非常依赖于这个大厂的声望。

比如你看微软给.net core 搞了一整套开源生态，但是不喜欢的还是不喜欢。

码农们最喜欢的生态背景，实际上是一个由多个厂商共同赞助的第三方基金会操持的形态，并且这个基金会最好是只负责这一家，而不是 Apache 那样杂糅的。

@also24 是 20W→45W

@liuhan907 .net 5 + EF 的跑分大致上比 NestJS + TypeORM 快一倍左右，但我查到 EF 在多表时性能可能会被 Dapper 甩开 8 倍？

我想知道一下具体的情况是怎样的，以及在复杂场景下 EF 和 TypeORM 这样的东西相比体验如何。

确实，跨语言再跨框架的对比显得有些奇怪，不过既然只有这俩，并且 TS 的语法风格也很 C#，所以还是比一下好了。

我这边作为基础的对比，我可以首先确定 EF 的 LINQ 在用 Lambda 语法的时候吊锤 TypeORM 的 QueryBuilder，感觉就像在操作 pandas 一样方便。但你不是第一个和我提到 EF 性能存在问题的，然而大家都语焉不详，.net 社区在寻找答案的时候又经常会找到过期内容，所以这方面如果能说的更详细一些的话就再好不过了。

@yyfearth 它可以直接去掉也可以细一点，现在实在是太宽了。
拖动可以参考 safari，空白的地方都能拖。

这么挪了一下之后觉得标题栏真的巨累赘了，大大的空空的一长条，还不如把窗口控制按钮放地址栏那一排最右边呢。

@shuimugan NestJS 之前试用过，但是现在看到它已经这么完善了还是有点惊讶，总的来说它的生态环境是比 FastAPI 更好的。

功能方面有我之前很痛点的 Session 支持一类的，功能更完整一些。

跑分方面大致比 FastAPI 高约 20%，而且因为是 V8，所以逻辑复杂了的话性能会甩的更开一些。

ORM 方面 TypeORM 也满足需求，功能比 Tortoise-ORM 更齐全，比如迁移一类的也都有。

如果不嫌弃 TypeScript 各种 JS 的智障遗产都有这一点的话，NestJS 已经可以直接替代 FastAPI 了。

@iConnect 有栈模式在 web 环境下比不过无栈吧？毕竟 web 场景下 io 密集而计算不密集，有栈会破坏预测并且需要频繁切栈和分配内存。

以及，主打有栈模式的现代语言只有 go 来着？

@liuhan907 但是 diesel 是同步线程池的…就有点可惜了。

@jtsai 果然对标的只有 C#吗，感觉香是真的香，但是国内也确实冷门了点。

@tabris17 本身语言性能低吧，ASGI 也就比 WSGI 快一倍左右。
倒是 Spring 和 Gin 的跑分很低这件事让我蛮惊讶的。

给注释一个编译期语义真是我见过的最蠢的设计了——什么，是 go 啊，那没事了，挺正常的。

不好说的，主要是因为 m1 的待机功耗实在是太低了，是毫瓦级别的，intel 目前还做不到这么低。

@helloworld000 因为开源产品更不容易做恶吧。

@Tumblr 我投赞成，因为云输入提供的不是一个更大的词库，而是一个简便地跳过拼写生僻名词的方式。

说实话很希望这款输入法能添加云输入功能，我记得安卓上已经有开源输入法支持调用各家的云输入了。

@zyzll1234 embody 对颈椎支撑舒服？它不是没有头枕也没办法装头枕吗…我这边 embody 最多能说让肩膀好受一点。

雅黑比不上苹方我可能还信，比不上思源…中宫大了点就这么不受待见吗

aiohttp 到 fastapi 的重构没啥意义的，除非你原本代码真的稀烂到一点功能都加不进去了。
不然你还是去用 gin 一类的 go 框架重构吧。