CSDN|Rust 让人奔溃的那些特性！

本文插图
作者 | William Woodruff 译者 | Arvin ，责编 | 屠敏头图 | CSDN 下载自东方 IC 出品 | CSDN（ID：CSDNnews）以下为译文：
五年前，我写了一篇文章论述了我当时（至今）最喜欢的脚本语言Ruby让我讨厌的地方（https://blog.yossarian.net/2015/09/28/Five-Things-I-Hate-About-Ruby）。
今天，我将对我目前最喜欢的编译型语言：Rust做同样的事情。
就像最初写的关于Ruby的帖子一样，这些抱怨都是个人观点，反映了我目前对这个语言的最佳理解。就像写关于Ruby的文章一样，这篇也是出于对Rust的热爱而编写的。
闲话少说，让我们开始主题。
字符串地狱
我在开发过程中抱怨Rust中的字符串有两个大方向：
1.字符串类型之间的区别令人困惑
2.字符串类型之间进行转换的方法太多
字符串类型太多
我可以想到5种不同的方式来表示字符串[1] ，字符串视图或接受字符串形式的方法签名：

&str 用于表示借来的字符串
String用于表示自有的字符串
&OsStr 用于表示从操作系统借用的字符串
OsString 用于表示操作系统中自有的字符串
AsRef用于方法签名，表示一个廉价的&str引用

（我知道最后一个并不是真正的字符串类型，但是它经常出现在惯用的字符串处理代码中。）
作为Rust新手，这几种类型之间的区别非常令人困惑，也使得理解引用变得更加困难（为什么引用&String与&str不同？为什么我不能直接创建str？我从哪里得到&&str？）。
【CSDN|Rust 让人奔溃的那些特性！】 在字符串之间进行转换的方法太多
多种字符串类型和相关特征带来多种转换功能：

&str到String：在不考虑格式化转换或往返一个Vec或[u8]的情况下，至少存在这么多种， String::from ， to_string ， to_owned ， into
String到&str：as_str ， as_ref ， Deref<Target=str> ， &x[..]
适用于OsStr和CStr的类似（可能有损）方法

这些转换中的大多数在性能上是等效的， Rust社区似乎对哪些是“正确的”存在分歧。
我最终习惯于根据上下文使用不同的字符串（例如into ，表示要将a &str转换为a ， String以便可以将其返回， to_owned表示稍后将拥有该字符串的所有权）。
标准库差距
Rust标准库存在一些空白，这些空白使用户空间编程的各个方面都很痛苦：

当前没有获取用户主目录的方法。 std::env::home_dir被明确标记为已弃用，并且该文档鼓励用户使用第三方库dirs（但是该库已经不再维护，详见GitHub链接：https://blog.yossarian.net/2020/05/20/Things-I-hate-about-rust%20/l%20fn:2）[2] 。
没有标准的扩展方式~ 。 std::fs::canonicalize支持.和 .. ，但不支持~ 。这其实和上面一点有所重复。
无法通过系统shell调用命令。我知道system[3]命令有各种问题。我也同意它不应该是执行其他进程的默认接口，甚至应该被隔离以防止意外使用。但所有这些都没有改变这样一个事实--即这个命令偶尔会有用，在标准库中实现比最终开发人员直接使用sh-c更可靠。

没有标准的方法进行glob操作。似乎 glob第三方库是执行此操作的半官方方法。
这些都是公认的微小差距，所有这些都可以通过高质量的第三方库解决。但是它们会在开发过程中增加摩擦，鉴于Rust无摩擦的特性，摩擦是特别值得注意的。