连 ios 的邮件 App 都会在打开一封邮件，然后反复切走、切回一段时间之后，报错显示这封邮件异常，无法显示。

说实话程序员们的情商都挺糟糕的，好在开源是纯粹的理性和逻辑工作，嘴臭的多了去了，actix 大家不也还得用，linux 不也还得用。

懂得不因为嘴臭和情商就站队，其实是很重要的一件事。

mini 用户在这里。
如果你平时是一手托手机，另一只手操控，那么你不需要 mini 。
如果你深深地为 11 无法单手握持而痛苦，并且你平时一直试图单手操控的话，用 mini 。
续航上的话，mini 对我来说是传统的一天两充。
我是关了 5G 使用的，因为确实觉得 5G 只是噱头。

@xuegy 我完全没有尝试过不过 vs 是支持增量编译的，所以或许可以用 vs 的增量编译逐字符不停地编译，跑在后台或者别的什么地方？

https://develop.openfoam.com/Development/openfoam/-/issues/1936

所以结论应该是 ccls 配 VSCode 了，简单翻了一下 VSCode 也有专门的插件。

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

比如你看微软给.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 我投赞成，因为云输入提供的不是一个更大的词库，而是一个简便地跳过拼写生僻名词的方式。