@istomyang #7
Future 是一个 trait
Async_Trait 也是一个 trait ，
Async_Trait 是 Send 的跟其定义的 fn fun 的返回值（某个实现 Future 的) 类型是不是 Send 的，两者没有必然关系。

如果你直接写成一个 struct 或者 enum 恐怕就没那么容易遇到 rust 目前的类型系统表达缺陷。
直接从 trait 开始写但又没想得那么细，肯定会写得不顺手啊

不是很明确你的需求具体是什么，按照我自己的理解参与一下讨论：

Rust 异步编程，要么就**不要**隐藏 async/await 的语言机制，这种适合作为其他 Rust 编写的代码提供 crate 或者 lib 的方式来使用；

如果是作为跨语言的基础类库，提供给譬如 C/C++ C# 等等的情形，我个人的实践经验是，参考操作系统 API 设计（即 epoll kqueue iocp 等等）提供 C 接口来描述异步的数据交换，主要思路是把不同语言的异步机制用 C API 隔离开来，由两边的语言各自封装异步交互机制；

@bli22ard #7

std 的源码是公开的，你甚至都不用下载直接在我发给你的链接开始点两下就看到了。
就算你改成了支持 &mut 语义，如果 OS 不支持独占，难道你还能阻止别的调用者用同样的路径再开一个 File 吗？

@bli22ard 如果你对 std 的设计不是很满意，你的 OS 平台支持你在 Rust 中使用 &mut 语义的话，你自己重新包装一个 File 也不是很难啊

@bli22ard #2

https://doc.rust-lang.org/stable/std/fs/struct.File.html

Note that, although read and write methods require a &mut File, because of the interfaces for Read and Write, the holder of a &File can still modify the file, either through methods that take &File or by retrieving the underlying OS object and modifying the file that way. Additionally, many operating systems allow concurrent modification of files by different processes. Avoid assuming that holding a &File means that the file will not change.

请问这个引擎适合哪些类型的游戏后端？
是否可以举例说明？或者说市面上哪款游戏的后端可以用这个引擎帮助或参与实现？

根据你的描述，如果该字段每次都输出不一样的值，
我能想到的一种影响就是会影响 hash 的结果，
有可能会在 Rust 以为是不可变引用的情况下造成 bug

@Chad0000 #207

```
按你想的来，全自动驾驶后：
- 车子可能会贵些
- 出租车会便宜因为平台把司机的钱也挣了，有利润下降空间
- 停车费绕不开
- 综上自己保有车成本远高于租车，也高于现在的租车
- 如果机器人发展起来了既能做家务又能开车，智能驾驶的汽车将没那么重要。即如果让你选先买机器人还是智能驾驶的车，你会先攒钱买哪个呢？
```

1. 车子不会贵一些，因为工业产品边际成本是降低的，除非汽车的原材料发生了重大的变化，否则只会越来越便宜；现在的一手车价格可以证明我的观点；
2. 出租车一直都会比自己持有车辆更便宜，但出租车再便宜也不会影响私家车市场扩大，这也是经济发展历史能实证的；
3. 如果人人都有私家车了，通勤范围扩大了，那么传统的市中心就没有必要继续存在了；更理性来说，当你的车足够智能，为啥不能你上班之后开回家停？
4. 你说的对，但这跟我们的话题没关系
5. 当你有自己的车了，你会想把东西都放在家里，还是想拿出去外面使用？锅碗瓢盆每个住处都有，你觉得为什么有车一族想出去露营？

你的想象力依然是根据现状来展开的，你还没有意识到生活的很多因素其实是互相影响的。
所以智能座舱的重要性是被你低估了

@Chad0000 #159

```
你怎么不说机器人 nb 后，不管油车电车自行车，它都能开呢。我倒觉得这个比车子自己智能更 nb：因为车子智能后大概率个人不需要应有汽车但智能机器人可能每个人都需要因为懒
```

要是修仙小说里的仙人不能御剑飞行，那得多无趣啊？
所以当自动驾驶真的证明安全以后，反而是每个人都会想有车的，而且它很可能会是其他个人智能机器人的控制中心。

不管你怎么想，你无法否认智能座舱要么完全不应该出现，一旦可以出现那它就是很重要的。

如果你始终觉得车必须由人来开，那么这些确实没啥用。
但如果突然有一天大家发现车真的可以不用人来开，那个时候才开始卷智能座舱就已经太落后了。

所以这就是赌，这就是尝试。
喜欢一直摸鹰过河的老古董自然没法宽容对鹰的背叛。

@kkocdko
用到 Pin 的情况不多，会不会有可能是因为用 Pin 要多打字母并且没有语法糖呢？
因为大部分用 `&mut X` 的其实都可以更严格（也更安全地）用 `Pin<&mut X>` 也不会造成什么多打字母以外的实际困难

话说，有没有人有兴趣发明创造一个 rust 的方言

买车肯定能提升生活质量，哪怕是单身狗。
但是因为有买车冲动但又不知从何开始的时候，你先要做的事情是明确自己的想法和需求。

省心，省日常成本，省总成本，目前不能全部同时拥有：

1. 纯电：主打省心（保养简单），日常充电如果愿意等公桩谷时电价，或者有家充也算省钱，但要开很多才能把电池成本省回来；但是日常体验目前来说是最好的，开着不用想油价什么的问题；

2. 插电混动（ PHEV ）：主打省短期成本，车价格比纯电便宜，使用成本比纯油低，适合随心所欲地用车，没有续航焦虑，能适应很多计划外情形（长途、突发），但是保养会比纯电频繁一点贵一点；油价焦虑是客观存在的，所以其实不是很适合固定通勤路线的上班族，适合经常需要不定期出远门的；

3. 油车和油混（ HEV ）：纯油或者油混总成本其实是目前最便宜的（因为是最成熟的工业而不是因为先进）。但除非你真的只买最便宜的油车并且是那种预留一大笔钱来支付保养和日常耗费，否则你是省不出这个感觉的。通常来说，越穷的人越难按计划消费（很反直觉但是是真的），所以适合穷人买的便宜油车反而其实很难省出价值来。

用 C# 写网络应用，性能瓶颈不在于跨平台异步框架设计带来的 IO 开销，因为实际上都是直接利用底层 OS API (例如 epoll iocp kqueue 等等)提供的支持，也就是说做到了别的语言最多只能一样快。

性能瓶颈在于一些 corner case 下，GC 阻碍了资源（不仅仅是内存，还有内存上面你写的对象）的及时释放而导致的奇怪问题。尽管有 `IDisposable` 但还是会写得很痛苦，心智负担很高。

但如果你只是原型开发、快速开发简单业务，那么 C# 可以搞一搞。

V 友什么的最好了
t/980166

你的疑惑不在于 await ，而是你还没理解 协程（ coroutine) 和 线程 (thread) 的运行方式。
协程是对线程的分时复用，线程是操作系统提供的对 CPU 的分时复用。
Rust 的 await 是一种协程相关的关键字，你的理解是线程的工作方式。