音译词或者直接用原文往往是社区规模过小，或者圈子排外的体现。母语文章中出现大量外来语或音译词往往会对新入行者设置巨大的门槛，或者造成严重的排挤效应。
我估计当前能写异步相关文章、或者能发表针对futures相关评论的人大多数也能看懂英语原文，所以大家似乎也没有意识到中文文章中充斥着大量英语词或音译词对新来者的劝退作用。
近期我向其他人普及futures的一些概念时，发现了很多英语水平有限的人对英语词汇存在着严重的抵触感（这种感受各位可以尝试阅读一下充满着英语词汇的现代物理或者化学文章）。因而社区还是要尽快确定下来future概念的通用译法。至少能够使新手在掌握概念期间，不必头痛于无法理解英语词。
从future的英语源流来看，future本意为“未来”其引申链为：
未来->预期->期货->异步中的future概念。
也即，future本质上是一种返回值的“期货”而非“现货”。同步函数的返回值在函数返回时就是现场可用的现货，异步函数的返回值在返回时仍然是不可用的期货，需要等待（await）“期货合同”到期（也即使用条件具备的含义），才能获取到真正可用的返回值“现货”。
但是“期货”是一个有强烈金融学意味的词汇，是否适合在翻译中使用仍然存疑。但相比直接使用future，至少这种翻译有更强的望文生义的优势。是否将future意味期货仍然有待讨论。
翻译上，根据汉语习惯，建议采用2-4字的译法，避免音译，应采用意译且有助于望文生义的译法，降低外来者的学习门槛。在各种正式教学或技术分享类文章中，建议采用“译文（future）”的形式表述。
目前我考虑了若干可能的译法，请各位讨论，如果有更加信达雅的翻译方式，也希望各位提出，希望经过社区讨论后能够尽快形成标准的翻译文档。我提出的候选译法如下。
- 期货（原义为期待交割的货物）
- 期货量
- 期货返回
- 期包（期待返回的闭包）
- 等待包
- 未来值
当然，这种翻译需要结合Pending、Ready等概念。以“未来值”为例，Pending可以在教科书中表述为“未来值 尚未交付”，Ready表述为“未来值 已交付”等等。
包括其他常见的rust英语概念，尽快制定一份标准的翻译指南。
评论区
写评论其实说是“预期”，或者是“待定”，我倒是觉得有点像是“预订”。
对future的译法提个建议：
1、我觉得先比较深入地理解下future，这应该是一个函数、任务、闭包，在不确定、待定的未来（延迟）执行，返回一个值（是否是可选的？）
2、尽可能用一个覆盖范围比较广的词，避免绑定到特定的实现方法上，同时又要反映future在逻辑上的特征
3、尽可能不要绑定到期货上，因为期货有比较鲜明的未来指定期限交货的特征，对future函数来说不一定是这样
4、尽可能不重用副词来命名，因为副词用处太多，用在译名里容易导致歧义
我也没找到特别合适的译名，找几个抛砖引玉一下（函数/任务，替换成闭包也可以）：
未定函数/任务
待定任务/函数
待执行任务/函数
延迟函数/任务
未来函数/任务
期值？
感觉在官网的中文翻译以及官方文档的翻译里 明确就OK~~~~ 有个合适的中文翻译总比没有好
--
👇
jonirrings: 这个得工业界推动学术界，还是学术界推动工业界？
在其他框架、规范、语言方面的翻译是不是也要统一啊？感觉一不注意就摊得太开了，唉。
有时候为了统一理解就直接用原英文词了。
不要翻译了吧，中文的复杂度直接增加了理解难度。曾几何时，windows里的句柄，也就是英文的handler，简直就是逼死初学者。
我周日考虑了一种翻译方式：预期值。
这种翻译方式可以提示学习者，这个不是当前可用的值，而是预期可用的值，具备future的未来语义。同时，值的表述，表明其依然是一个值，同时可以避免单纯的使用“预期”一词有可能引发的歧义。
那么可以尝试用预期值去翻译标准文档中的这段话 https://doc.rust-lang.org/beta/std/future/trait.Future.html
A future is a value that may not have finished computing yet. This kind of "asynchronous value" makes it possible for a thread to continue doing useful work while it waits for the value to become available.
预期值是一个有可能尚未完成计算的值。这种“异步值”使得线程在等待预期值变为可用状态前，能够继续处理其他有用的工作。
提醒了我的注意，我以后也尽量用生存期(lifetime)去表述
--
👇
jamesmarva: 同意，我一直翻译成 “生命期限”，嘻嘻
--
👇
Nugine: 我认为 lifetime 应该翻译为 “生存期”，而不是“生命周期”，要与 lifecycle 做出区分。
我写 Rust 相关的文章时都会用“生存期”，不知道有没有其他人认同这一点。
中文社区应该一起做一份术语对照表，逐步统一表述。
同意，我一直翻译成 “生命期限”，嘻嘻
--
👇
Nugine: 我认为 lifetime 应该翻译为 “生存期”，而不是“生命周期”，要与 lifecycle 做出区分。
我写 Rust 相关的文章时都会用“生存期”，不知道有没有其他人认同这一点。
中文社区应该一起做一份术语对照表，逐步统一表述。
同意，对于有运行时（runtime）概念的语言，确实多少有点产生疑问，到底和lftecycle有什么区别。。看完我想知道了，但是又好像不知道。。。应该是没却别出来有太大的区别吧，也许Rust没有GC，实际上在作用域最后最后一行调用了drop。比如在java中不知道（确定准确的地方，时间）对象被销毁，但是在Rust中确实明确知道对象销毁的地方。
--
👇
Nugine: 我认为 lifetime 应该翻译为 “生存期”，而不是“生命周期”，要与 lifecycle 做出区分。
我写 Rust 相关的文章时都会用“生存期”，不知道有没有其他人认同这一点。
中文社区应该一起做一份术语对照表，逐步统一表述。
我认为 lifetime 应该翻译为 “生存期”，而不是“生命周期”，要与 lifecycle 做出区分。
我写 Rust 相关的文章时都会用“生存期”，不知道有没有其他人认同这一点。
中文社区应该一起做一份术语对照表，逐步统一表述。
支持!
对于英文过关的人而言没有问题，甚至直接读原文更好。但是我了解到，相当一批人英文水平根本不过关，他们可能需要一个标准的翻译方案，才有入门的可能。
也不知道历史上的“字符串”、“整型”、“函数”、“指针”、“数组（array 其实是阵列（来自军事学））”这些概念是怎么翻译过来的。当年还没有数组翻译的时候，看到array这个词的人，所感知到的应当是成排成列的士兵的那种感觉。
这个事情一定是学术界推动工业界，学术界才需要让更多的人跟着自己的路线走，工业界更多的会试图垄断自身的优势以维持自己的竞争力。
rust里诸如 “绑定 binding”、“泛型 Generics”大多引用自已有的译法。但trait、crate这些全新的概念，就很不好处理。trait表达的是“公共特征”的含义，crate的原始含义就是crates.io的那个徽标（logo）。
中文程序设计行业的许多术语应当受“谭浩强”那一批最早的教科书作者的翻译惯例影响很深。但互联网时代社区模式下，却不常见翻译惯例的形成。
--
👇
jonirrings: 这个得工业界推动学术界，还是学术界推动工业界？
在其他框架、规范、语言方面的翻译是不是也要统一啊？感觉一不注意就摊得太开了，唉。
有时候为了统一理解就直接用原英文词了。
炒期货太难了，比rust的unsafe + async还难。
--
👇
zhuxiujia: 学了future 同时学会了 炒期货，多好
Promise的含义是承诺。这同样蕴含者一种“当下没有，以后再给”的含义在里面。对javascript而言，这里可能翻译成“承诺量”会更好一些。
task就没有很强的promise、future这种“未来”的语感。
目前我不是很确定他们是不是要使用一样的翻译，我倾向于不一样的翻译。一旦弄成一样的翻译，未来一旦Promise和Future发展向不通的语义，反而会在中文层面造成混乱。对于两种语言都用的人，能够自然意识到这两个是类似的东西。
--
👇
Rynco Maekawa: 可以考虑和类似的概念
Promise(Javascript) 和Task(C#) 采用类似的翻译？学了future 同时学会了 炒期货，多好
可以考虑和类似的概念
Promise(Javascript) 和Task(C#) 采用类似的翻译？这个得工业界推动学术界，还是学术界推动工业界？
在其他框架、规范、语言方面的翻译是不是也要统一啊？感觉一不注意就摊得太开了，唉。
有时候为了统一理解就直接用原英文词了。