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

根据你的描述，如果该字段每次都输出不一样的值，
我能想到的一种影响就是会影响 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 是一种协程相关的关键字，你的理解是线程的工作方式。

@qianjian #17

如果不考虑开发成本、维护成本、沟通成本的话，确实是什么都能写啊。
哪个领域可以用 C++ 几乎都可以用 Rust ，没人提起，是因为 Rust （的名声）积累还不够深。

欢迎新的 Rustacean~！

Rust 是否能够有效减少锁使用，对这个问题有怀疑的程序员朋友们，可以尝试挑战一下实现这个。
在假定使用者不能使用 unsafe 或者别的魔法的情况下，设计一个既可用于多线程，又可以用于单线程的支持异步操作的 ring buffer ，其隐含的约束或者需求是：只允许有一个写入端和一个读取端
我用 C# golang C++ Rust 都试过。
结论就是 Rust 确实不需要额外加锁，仅仅依靠类型系统在编译时就能保证使用者一定满足上述约束。
其他语言只能通过额外对 ring buffer 加锁保证，或者只能靠文档保证。

Rust 神教教徒来传教了，不喜请忽略。

我跟你一样，对数据库的查询引擎和存储结合的部分很感兴趣，也觉得 CPP 的心智负担真的太大了，没办法让我在快速试验想法的同时，能够积累一些代码用于下一次的迭代。

如果只是要快速迭代，那可能用脚本语言或者别的灵活性很高的语言是可以的，但问题是这些语言虽然表现力强但是性能真的很成问题，很难用于积累。

所以 Rust 真的很适合，它的类型系统能够帮助你以很正交的方式来描述抽象设计，零成本抽象的设计原则提供了良好的运行时性能。

作为一个曾经的 CPP 程序员，我认为 Rust 真的不需要知道什么奇技淫巧或者 corner case 就能用得很好；当然这对于很多人来说，可能 Rust 的门槛真的很高，因为他们不一定需要这么强力的工具。但以你的目标来看（ DBMS 核心组件），Rust 应该是恰当的。

@yannxia #198
我反正无所谓我是不是愚昧，我又不是无所不知。
但是你说我站在他们的对立面，那你肯定又是愚昧了。
反对“单踏板模式”的人里面，会持有什么观点我非常清楚并且很理解。
倒是你有没有问过他们，有没有开过可调节动能回收、定速巡航或者全速自适应巡航，
如果他们知道这些的话，电车不可以松开踏板放在刹车踏板上备刹吗？这时候和油车有任何区别吗？
愚昧就是愚昧，不会因为有自己的理由就不是愚昧

看完所有回复，OP 有没有觉得人类的愚昧真的很顽固？哈哈哈哈~

就是有那么一部分人，既不能从文字描述中感知叙述者的感受，也不愿意亲自去感受，
然后坚持以自己的想象否定叙述者的体验。

所以我一直认为，一线销售人员应该是一种技术工种。