@bli22ard Rust 是系统级的语言，除了你说的应用场景还有其他的情况，例如:
1.没有原子变量的平台，例如某些嵌入式，他们没法使用 Arc
2.没有堆分配器的平台，这些平台和 1 类有些重合，他们不仅没法使用 Arc ，还无法使用任何依赖堆分配的智能指针。
3.不希望支付 Arc 开销的应用场景，比如单线程并发读写

如果标准库只是简单的套 Arc ，那么其 split API 对上面两个应用场景就是毫无价值的，他们还是要自己实现其常见的 split 方法，例如:
```
fn split(stream: &TcpStream) -> (ReadHalf<'_>, WriteHalf<'_> {
// 常用于栈上协程
}

fn split(stream: &Rc<TcpStream>) -> (ReadHalf, WriteHalf) {
// 常用于单线程
}
```

你说的应用场景是重要的，但 Rust 标准库的设计不能仅仅关注在某些重要领域而忽视其他的需求。这时候你反观标注库的实现，就会发现对内部可变的文件实现 Read, Write 是一个折中的方案，以上情况都可以简单的利用其满足自己的需求。你说它完美吗？那肯定不是，我相信也会有更好的实现方式。但在更好的设计被提出之前，我觉得标准库的实现是正确的。

讨论设计问题不要从你当前的需求出发，而是要把其他需求也考虑进去。比如你认为标准库应该提供 split ，那么它应该如何实现呢？

```
let (app_type , user_info) = {
let queries = Queries::from_uri(request.uri()).unwrap_or_default();
(AppTypeExt::get_from(&queries)?, UserInfo::get_from(&queries)?)
};

if let Some(app_type) = app_type {
request.extensions_mut().insert(app_type);
}

if let Some(user_info) = user_info {
request.extensions_mut().insert(user_info);
}
```

我觉得无所谓，我关注的是交流的对象，内容和目的。

你没错

如果这个世界是因为我观测而存在，那么我只能说我真傻逼怎么不选个好点的座位。

对是否使用 ts 不做评价。但很明显这个项目就是一言堂，对这种项目最好不要做任何贡献。

@Baloneo 如果你浏览 tfb 可以参考下 robyn 的分数，横向比较也并没有很快的感觉（我对 py 库了解不多）。https://www.techempower.com/benchmarks/#section=test&runid=074e8a70-d6fb-4f10-82f3-43e57c0965b5&test=plaintext&l=hra0hr-35r

哥们儿你那个附言我笑了，压测 404

@datou552211 如你所言。不过我的意思并不是中文圈不行，而是 rust 这个语言发展很快同时其社区又很现代。中文资料容易过时，也很难覆盖社区讨论(例如 zulip, discord 等)

如果你英语还可以，那么学 rust 最好不要看中文资料。

有一种说法生命是宇宙体验和检视自身的方式。

gui 和 embedded 目前都不是 rust 长项

是你的业务面向高级抽象，才会有这种错觉。