同事们，大家晚上好！
我们很高兴为您提供
Raf Levin撰写的真正程序化文章的翻译，该文章对Rust语言的发展所产生的巨大影响唤起了人们的敬意和崇敬：
在没有虚假的谦虚和仇恨的情况下，一位客观而热情的受人尊敬的作者对Rust社区的呼吁做出了回应，Rust社区在本文开头以引用的方式发表。 我们希望它能带来有趣且肯定的生活。
最近，Rust核心团队
提议撰写文章 ，对Rust在2019年应如何发展发表看法。 这是我的意见。
成熟的生命周期在本文中，我将以极为简化的形式考虑成熟的生命周期。 让它仅包括三个阶段：研究，开发，抛光。 Rust的各种元素的成熟度不同。 在尝试准确描述语言开发的当前阶段时，尤其是将其带入下一阶段时，必须考虑这一点。 例如，在我看来，该语言主要处于“抛光”阶段。 如果坚持“研究”阶段尚未完成的事实，那么可以通过依赖类型，
虚拟结构等来丰富该语言，这将很有趣，但适得其反。 反之亦然：我们无法准确地说明图形用户界面中缺少的内容，因此过早尝试将这些搜索引入标准解决方案可能会导致结果欠佳。
在许多成熟的产品中，发行版本是交替的，其中一些致力于运行新功能，而另一些则致力于其稳定性。 例如，这就是英特尔的壁虱系统。 安卓（Kat Kit）和棉花糖（Marshmallow）的版本稳定，而棒棒糖（Lollipop）正在积极铲除。 在2018年，Rust增添了许多新功能，因此我认为现在是稳定阶段的时候了。 在这一点上，我同意
乔纳森·特纳 （
Jonathan Turner ）以及其他许多人的观点。
锈语言我认为，Rust语言基本上已经准备就绪。 似乎社区已经同意需要“登陆”仍在运行中的那些功能（正在开发中）：我们正在谈论异步/等待，const泛型和解释器（这可能会为我们提供修订
通用关联类型 ）。 但是，我认为最重要的是，我们不应该太热衷于在管道中添加新功能。
零花钱。 截至2018年，已经写了两本关于Rust的优秀书籍，但两本都已经过时了。 限定路径的约定在其中有所不同，现在我们使用
dyn Trait等。 更改越动态，给用户带来更多的不便。
有很多因素限制了Rust的成功。 我认为这些缺点中的大多数并不是语言本身固有的。
索具Rust钻机本来可以更好。 我使用RLS进行了实验，但始终返回到常规的文本编辑器和命令行循环中（老实说，我最近没有进行此类实验）。 我认为，从长远来看，需要对Rust工具进行重大修改，以至少在某种程度上缓解学习难度。 我对温室语言有一些想法（我希望有时间来详细解释它们），我不确定其中哪一种可行，价值与链接之间没有明显区别，搬迁后可以使用该价值，等等。 。 原则上，这种语言将允许将字符串视为数字。 服务器接受用这种语言编写的程序，迅速对其进行纠正，并将其转换为成熟的Rust。
自然，RLS仅对应一半，用户通过编辑器与其进行交互。 尽管通常需要一些指导和支持，但使用
xi-editor进行操作很方便。 这项工作是由
Colin Rofles领导的社区进行的，我很高兴看到这个编辑器的改进（它已经成为我的主要编辑器）。 它提供对语言服务器的支持以及新功能，例如常规注释机制，该机制将在2019年更好地完成。
图书馆生态系统现在，最热门的工作正在为Rust创建库。 在下面，我列出了我计划自己做的事情。
我想提出的主题之一是“连贯性”，我认为它是Rust的最有价值的功能之一，以及
其类型系统的
技术组成部分 。 C ++中“游戏引擎”的许多组件都是经过精心准备的，相互交互良好的库。 但是在Rust中，许多事情都是有机发生的。 容器实际上通常会被磨碎以用于捆绑销售，如果您正确使用诸如in之类的东西，那么一切将会越来越好。 第二类的一个特别令人信服的示例是
mint ，它确保了许多数学容器的互操作性，即使用于定义向量类型的约定在它们之间并不相同。
SIMD我认为SIMD库仍在调查中。 有许多包装器库，每个包装器库都提供了稍微不同的观点和不同的权衡方法：
simdeez ，
packed_simd ，
更快 ，当然还有我自己的
fearless_simd 。 这些折衷绝非无条件的，因为有些用户需要将所有性能从语言中挤出来，直到最后一滴，如果您偏向这种极端，则必须针对特定处理器诉诸最佳指令。 其他人会欣赏可移植性和安全性。
SIMD最重要的错误之一是，编译器需要完成更多工作，主要是为了与AVX-512和非x86 SIMD体系结构进行交互。 包装器库还可能需要在语言级别进行一些更改，以使工作尽可能方便。 因此，目前，嵌入和
cfg(target_feature = ...)交互作用较差。 我认为，这是另一个需要研究的问题。 有趣的是，在语言级别上无需其他支持，我们还能走多远？究竟有哪些功能可以从根本上增加使用它的便利性？
音讯有便捷的低级音频容器，其中应特别注意
cpal 。 但是，在性能级别上可能会有困难（容器并不总是使用实时流），这是有可能的。 有必要找到最佳方法：修改cpal或开发一个可以解决特定问题的新容器。 为此，尤其是，您需要仔细查看C ++库，例如
RtAudio ，它很好地解决了这些问题。
对于更高级别的音频合成，我对
synthesize-rs有很大的计划。 此选项并不适合所有人，但我认为这是各种合成技术和音频效果的良好基础。 如今，这一工作领域似乎处于研发阶段之间。
要继续进行此操作，请在我们的Zulip聊天中查看
#synthesizer流 。 在11月，我就此作了一次讲座，并计划在此基础上尽快写一篇文章。
图形用户界面图形用户界面目前是Rust的最弱点之一。 我认为在2019年我们将在Rust社区中看到很多有关此主题的文章。
就个人而言，在我看来，Rostov GUI现在应该归于“研究”阶段。 许多替代方法正在制定中，到目前为止，关于哪种方法最好没有达成共识。 2D图形和其他用户界面原语应在系统体系结构中使用的积极程度如何，还是我们应该自己实现整个堆栈？ 是否有必要（使用wasm）部署到Web？ 整个编程过程是否应该被视为“ Rust-native”，还是更好地适应某些成熟的GUI中建立的约定？ Rust社区是否有足够的资源来创建新的GUI工具包，如果这样，是否值得？
我开始了一个
Druid项目，为我的合成器和游戏制作GUI，但这是一个研究项目。 它代表了我的观点，对以上所有问题的解答，并且我认为该项目进展良好。 但是，我重复一遍，这是一个研究项目，在现阶段将其引入其他项目将是非常愚蠢的。
此外，许多其他GUI开发项目正在进行中。 在我看来，其中最有前途的是
Azul ，因为我喜欢WebRender作为构建GUI的基础。 另一个非常有前途的项目是
OrbTK ，它是基于Redox的，但是跨平台并且非常先进。 您可以从
Conrod ，
ggez的示例以及其他语言的工具包装中学到很多东西。
毫不奇怪，Rust中最激烈的GUI开发活动与游戏密切相关，在我看来，这很好。 创新在游戏领域扎根更好，对成熟工具的需求在这里并不是那么紧迫。 但是，一旦出现了一种在Rust中实现GUI的极好的方法，我认为它将找到最广泛的应用。 我还注意到，我的Druid基于GUI级别源自
Windows的
xi客户端编辑器 。
标记pulldown-cmark库使用得很好，尤其是用于rustdoc，但在某些方面已被弃用。 它的发展跟不上CommonMark规范的发展。 它卡住的原因之一是解析算法。 我已经有了一个如何为此目的编写新算法的想法，比以前好得多。 但是我还没有弄清楚细节。 最近，我
回到了这项工作，并准备发布一种算法。 当将
new_algo分支添加到master时，我认为社区应该进行进一步的开发，并使其具有新功能。 我正在考虑完全GFM兼容性，数学，也许还有其他类似的东西。
感谢Rust社区中的每个人来确定我喜欢的语言。