也许我们可以拥有美好的事物

编程语言通过引入新的约束条件而得以发展。我们不对所有内容都使用汇编语言的一个关键原因是，由于缺乏约束，因此日常编程都很难使用。在被认为有害之前

，人们编写了无处不在的机器代码，程序员不得不维护整个机器状态以及每次跳跃的全部含义的思维模型-这是漏洞的解决方法。引入了：结构化语言仍然可以编译为getos（或任意跳转），但是程序员可以考虑更有限的跳转：if，switch / case，call，return，for。这些受约束的跳跃更容易理解；例如，当您阅读代码时，您可以知道return并不仅仅返回任何地方。它仅返回给调用者，由堆栈上的指针标识。后来，语言设计人员添加了其他受约束的跳转，例如throw / catch和虚拟函数调用。 （根据我的口味，投掷有点太偏了，因为您无法在本地说出相关的捕获块在哪里。但这是另一个故事了。）

，这实际上是“背负”堆栈的价值，并通过更多的功能丰富了它。 （附加的复杂性通常是可以控制的，并且值得）。它允许您扩展堆栈提供的自动内存管理，初始化和清除复杂的资源，而不仅仅是原始值（如整数和浮点数）。您可以自动关闭打开的文件，释放动态存储等。而且是确定性的。但是仍然存在堆的问题：没有约束的自由发射区，内存泄漏（已分配堆资源但从未释放）和无用后的bug（堆资源即使在释放后也得到了重新使用）充满了混乱。

，使我们可以更彻底地解决最严重的剩余内存不安全问题。 （以前对堆生存期问题的解决方案是动态的，而不是静态的，因此在空间和时间上都是昂贵的，而且是不确定的。这些限制降低了动态管理的语言在负担这些费用的应用程序和环境中的适用性。）当然，驯服对象的生命周期可以大大缓解安全，高效的并发问题。并发是提高现代系统性能的关键。

除了内存安全性之外，Rust还比我在其主流产品中其他主流语言中通常看到的更多地使用了可键入性。例如，Rust丰富的枚举和模式匹配使编写状态机变得更加容易，新的类型习惯使获得附加的类型安全性（并改善了“文档接口”）更加容易，等等。您可以努力获得其他语言的类似好处，但是Rust的句法机制和惯用用法为这些更简单的模式提供了实惠。

Rust引入的另一个释放约束是系统化和自动化依赖项管理：货运包裹管理系统。良好的依赖性管理是一个非常困难的问题。任何依赖关系管理系统，包括手动或临时管理，都会带来各种问题：

版本冲突：不可避免的是，最新版本的foo软件包已更改其API，使其无法与barpackage进行互操作。现在解决依赖关系树上所有这些冲突。

供应链安全性：引入依赖项时，必须信任已提交给该依赖项子树的所有作者的传递性关闭。这不仅包括您可以使用其构建的代码和程序，还包括构建脚本本身。

微观甚至微妙的依存关系：倾向于通过创建极小的微小问题来乘以先前的两个问题

，一次性包装。扩散：倾向于通过创建满足相同基本需求的多个程序包来使前三个问题倍增，从而导致解决相同问题的工作分散化的情况-包括文档，培训，代码审查员/审计员时间等。 （我称之为“ Occam的剃刀现在有5个刀片

NPM生态系统提供了这些问题的最清晰的现代例证。 （请参阅Github安全报告的第11页

例如。）但是，对于NPM的所有问题，至少它是一个软件包管理系统！选择NPM（或CPAN等前身产品）很容易

，或CTAN，或...），但即使在最坏的情况下，它也比手动管理依赖项（例如，通过将它们手动供应到源代码树中，或者只是告诉用户在尝试编译之前安装此类库）有很大的改进）。 NPM，Rust的Cargo，Go的go get等使生活变得更好。即使它们还不是很完美，它们也会通过约束依赖来自何处以及我们如何维护它们来提供改进框架。

但是仍然需要大量工作。举例来说，Cargo有一个名为供应链的附加组件

，这将向您展示给定包取决于的所有包。它将还会评估有多少个发布者作者作者编写这些依赖项。在这里，当您运行供应链本身时：〜/ src /锈/货物供应链％货物供应链发布者将忽略以下箱子，因为它们来自当地目录： - 货物供应 - Chainthe`板条箱未找到.IO`缓存或它无效。运行“货物供应链更新”以生成它。来自箱子的发布商信息.IOTHIS由于API率Limitsfetting数据为＆＃34; Adler＆＃34; （0/79）[77项，包括一些令人惊讶的项目，Leated ...]获取＆＃34; XATTR＆＃34; （78/79）以下个人可以发布依赖关系的更新：1。AlexCrichton通过链条：Flate2，WASM-BINDGEN-后端，WASI，BitFlags，Proc-Macro2，WASM-BINDGEN-MACRO，WASM-BINDGEN，OPENSSL-PROBE ，Unicode-xid，WASM-Bindgen-宏支持，文件，Semver，Tar，Unicode-rancormization，Libc，JS-Sys，Bumpalo，Log，WASM-Bindgen-Shared，CFG-IF，CC，Web-Sys [55作者所选择的......] 57.通过板条箱的Zesterer：Spinnote：可能有优秀的出版商邀请函。 Crates.io没有提供列出它们的方法。撤消也无法撤消，而且他们从未expire.se https://github.com/rust-lang/crates.io/issues/2868获取更多信息。所有的成员以下团队可以发布依赖项的更新：1.＆＃34; GitHub：Rustwasm：Core＆＃34; （https://github.com/rustwasm）通过箱子：web-sys，js-sys，wasm-bindgen-macro，wasm-bindgen-accro-support，wasm-bindgen-beftend，wasm-bindgen，wasm-bindgen-共享2.＆＃34; GitHub：伺服：Cargo-Publish＆＃34; （https://github.com/servo）通过箱子：核心基础 - sys，百分比 - 编码，form_urlencoded，unicode-bidi，核心基础，idna，url 3.＆＃34; github：伺服：rust-url＆ ＃34; （https://github.com/servo）通过链条：编码百分比，form_urlencoded，idna，url 4.＆＃34; github：rust-bus：维护者＆＃34; （https://github.com/rust-bus）通过箱子：安全框架 - sys，安全框架，tinyvec 5.＆＃34; github：rust-lang-托儿所：libs＆＃34; （https://github.com/rust-lang-nursery）通过箱子：bitflags，log，log，lazy_static 6.＆＃34; github：serde-rs：业主＆＃34; （https://github.com/serde -rs）通过箱子：serde_derive，serde，serde_json 7.＆＃34; github：rust-lang：libs＆＃34; （https://github.com/rust-lang）通过链条：libc，cfg-if 8.＆＃34; github：rust-lang-托儿所：记录业主＆＃34; （https://github.com/rust-lang-nursery）通过链条：log 9.＆＃34; github：rust-wandom：维护者＆＃34; （https://github.com/rust-random）通过链条：getrandomgithub团队是黑色盒子。如果没有明确许可，它是不可能获取会员名单。〜/ src /锈/货物供应链％货源链供应链UpdateNote：这将下载大量数据（约250mb）.on慢网络需要一段时间。

现在，这是我不知道的很多出版商的很多依赖。（虽然它不是自动化的，如果你挖掘你会发现许多TheSeauthors是生锈开发团队的成员，所以信任是一个更容易的卖。 （我的旗帜非常垂直：-weverything -Werror -Std = C11。很少的代码用ThemoPlags构建。😇）显然，一些供应链自己的依赖关系取决于C代码。

但那没关系！货物提供了一个努力解决这些问题的框架。加班，我想看看事情沿着这些线条移动：

用Rust替换C / C ++依赖关系，并减少不安全的使用。这已经发生，并将继续，随着时间的推移。（参见安全舞曲，这是一个专注于减少不安全的使用。）

将最常见的依赖性与（半）官方的“扩展STD”结合，以便它们可以作为单一依赖与单一的团队。这在某些社区存在争议，但我认为这将是减少问题的漫长方法。

通过将它们折叠成较大，更多的套装包，包括语言本身，STD和“扩展STD”（在哪里以及适当的方式）来避免一些微依赖性。这也是有时候，但我认为它会有所帮助。

也许供应链，检查，clippy或一个新工具可以提供包装的声誉或类似于Perl Communitjokingly称之为kwalitee：不是质量的东西，而是整体“闻起来”。良好的测试覆盖范围？ Package VersionGreater小于1.0吗？积极维护？经常使用？长期以来一直由他人维持？不安全块中的代码中的一行或在C / C ++ /组件中的低比例这些东西中的一些可以更多或小于自动确定，并且工具可以标记脱颖而出的包裹。 Funupdate 18月18日：这样的东西存在，并且被称为crev

。惊人的！ Rust的另一个优点是其友好的社区。并非所有的系统编程社区都像Rust一样受欢迎。 Rust和其他一些社区已采取积极措施来维护健康的社区

。我认为可以说Rust社区做得相对不错，尤其是在系统编程领域。像所有语言社区一样，无论是自然语言还是人工语言，社区和文学主体以及口头传统都至关重要。在其利基市场中，Rust看起来是围绕一个更积极，更健康的社区发展最快的选择。社区和语言可能不是完美的-哪怕是完美的东西也没有-但是Rust似乎是社区最愿意解决其问题，并且最有能力解决系统编程问题。

感谢供应链维护者谢尔盖·戴维多夫（Sergey Davidoff）为我指出了自信，并指出“安全之舞”的目的在于减少不安全感。

克里斯·帕尔默（Chris Palmer）撰写的Noncombatant.org位于创用CC，受Attribution-NonCommercial-ShareAlike4.0国际许可的约束。