本篇是对 RustConf 2023中的Rustacean Community Interfaces: A Tale of Many Hats这一视频的翻译与整理, 过程中为符合中文惯用表达有适当删改, 版权归原作者所有.
我会按照您的要求整理内容,并将其翻译成中文,不会遗漏或总结任何内容。以下是整理和翻译后的文本:
亲爱的Rust同仁们,很高兴能与你们相聚在这里,无论是在这座伟大的阿尔伯克基市,还是在世界各地的在线观众。
当我们在这次会议的语境中提到”Rust”时,会想到几个不同的方面:
Rust是一种编程语言,这是我们今天大多数人来到这里的原因。Rust也是一个编译器,它的错误信息从不羞辱我们,而是指导我们写出更好的代码。Rust还是一个生态系统,包括库、框架、二进制文件等等。所有这些Rust的方面都依赖于Rust开源社区。
现在让我们深入了解一下Rust社区。Rust社区包括项目本身的成员、Rust基金会和Rust crate的维护者。让我们为这三个群体鼓掌。
[掌声]
我们的社区还包括那些通过课程、书籍、教程等方式教授我们Rust的教育工作者。这里有谁从Rust教育工作者那里受益过?好,让我们为所有这些教育工作者热烈鼓掌。
社区还包括那些组织我们聚会和活动的了不起的个人,比如我们现在参加的这个活动。让我们为Rust大会的组织者和所有了不起的志愿者热烈鼓掌。
最后,我们的社区还包括Rust用户。所谓Rust用户,我指的是任何对Rust感兴趣的人,无论处于什么水平,担任什么角色。这意味着你们每一个人都是Rust社区的成员。再一次,为自己鼓掌。
[掌声]
我们在场的许多人,无论是现场还是在线,都属于不止一个群体。你可以说我们戴着多顶帽子。例如,我是”This Week in Rust”的主编,这是一顶帽子。这里有谁订阅了”This Week in Rust”?太好了。我当然希望那些还没有订阅的人能够注册。尽管我是”This Week in Rust”的主编,但我远不是唯一的编辑和审稿人。没有我团队中令人难以置信的成员,This Week in Rust就不可能存在。我离不开他们。
除了我的”This Week in Rust”帽子,我还是Rust基金会的董事会成员。今天有多少基金会工作人员和董事会成员在场?我们看到几只手举起来了,我知道在Rust基金会的展台那里肯定还有更多人。如果你对基金会有任何问题,请随时在会议期间与这些人交谈。
最后,我还戴着微软首席工程师的帽子,我有幸在工作中使用Rust。我知道我不是唯一一个戴多顶帽子的人。
当我们戴着许多不同的帽子时,有效沟通可能会成为一种挣扎,特别是因为很难知道在任何特定时刻应该戴哪顶帽子。当两顶帽子之间存在冲突时,情况就更加困难了。如果我们在一个领域的职责和义务与另一个领域的职责和义务发生冲突怎么办?好吧,我们稍后会在这次演讲中讨论如何处理这个问题。
当我为今天的演讲做准备时,我试图找到一个比喻来解释我们Rust社区成员相互沟通的不同方式。我回想起几年前在Rust Belt Rust大会上的一次演讲,当时我使用了龙与地下城的比喻来解释Rust特征。那是迄今为止我最受欢迎的演讲。所以我的第一反应是再次转向龙与地下城的比喻来做这次演讲。然而,当我写这个演讲稿,经过几次修改后,我意识到,就像我们可以用现实生活或幻想的比喻来解释技术概念一样,我们也可以用技术比喻来解释现实生活的概念。
让我们从用Rust中的结构体来表示一个Rust社区成员开始这个比喻。在Rust中,我们经常使用结构体或类型来表示数据。在这个结构体中,我们将名字和电子邮件地址存储为字符串。让我们创建这个结构体的一个实例。这是Nell Rust社区成员结构体,存储了我的名字和电子邮件地址。
现在我们有了数据,我们还需要为这些数据定义一些行为。让我们想想所有Rust社区成员都可以做的一些行为。其中一个行为是在Rust RFC’s GitHub仓库中打开一个RFC(意见征求)。此外,作为Rust社区成员,我们还可以对RFC进行评论。这就是意见征求的全部意义 - 从整个Rust社区收集意见。
当我们用Rust编程时,我们经常使用特征来捕捉可能在不同类型之间共享的行为。所以让我们继续创建一个RFC特征。这是我们的特征,现在让我们添加一个特征方法来打开RFC,再添加另一个方法来评论RFC。尽管我没有在幻灯片上显示细节,但让我们假设这两个方法都在特征中有默认实现。在特征中,当我们有方法的默认实现时,除非我们在实现特征时覆盖它,否则将使用该实现。
说到实现,让我们就这样做,在我们的Rust社区成员结构体上实现RFC特征。如果你昨天参加了Rust培训,这可能看起来很熟悉。这允许Rust社区成员结构体的实例访问和使用特征方法。让我们看看实际效果。
这是我们的Rust社区成员结构体实例,如果我们尝试使用open_rfc方法,由于我们在结构体上实现了RFC特征,这段代码将成功编译。同样,当我使用comment_rfc方法时,它也会成功编译。所以,太好了,我们创建了一个结构体来表示一个Rust社区成员,还创建了一个特征来表示与RFC相关的行为。
让我们再想一想,所有Rust社区成员还能做什么?为This Week in Rust做贡献。我真心希望你们今天在场的许多人,以及许多在线观看的人,能写下你们在Rust大会的经历,并提交给This Week in Rust。
为了在我们的技术比喻中捕捉这种行为,让我们继续创建另一个特征: contribute_to_this_week_in_rust。然后让我们添加一个特征方法来打开GitHub拉取请求,这是向This Week in Rust提交内容的最佳方式之一。
现在让我们回到我们的Rust社区成员结构体,我们已经在其中实现了RFC特征,让我们继续添加contribute_to_this_week_in_rust特征的实现。现在所有Rust社区成员都可以使用这个特征的方法了。让我们看看实际效果。回到我们的Rust社区成员结构体实例,我们再次尝试使用open_pull_request方法,它成功编译了。太好了!
到目前为止,我们已经看到了所有Rust社区成员(包括你们每一个人)都可以做的几个例子。但是有些事情只有某些群体的Rust社区成员才能做。例如,编辑This Week in Rust。任何人都可以为新闻稿做贡献,但只有This Week in Rust的编辑才能编辑它。
为了说明这一点,让我们创建一个新的结构体。这是TWiR(This Week in Rust的缩写)编辑结构体。这个结构体有一个rust_station字段,存储了Rust社区成员结构体的一个实例。我喜欢把这想象成一个戴着编辑帽子的Rust社区成员。这种将一个结构体的实例与另一个结构体的实例关联的模式在Rust中被称为结构组合。
如果你听到这里在想:”等一下,在Rust社区成员结构体中使用泛型类型字段不是更适合这个例子吗?”答案是,在真实世界的代码中,是的,泛型类型可能会更好。但为了比喻的需要,以及为了防止幻灯片变得太复杂,并且保持在这次演讲的时间限制内,我选择在这些例子中使用结构组合。如果你想更多地讨论这个问题,欢迎在会议期间找我聊天。
回到我们的代码,编辑This Week in Rust是一种相当独特的行为。我们不太可能与不同的类型共享这种行为。因此,与其使用特征,不如直接在结构体上实现一些方法。让我们从merge_pull_request方法开始。合并拉取请求的能力是编辑的核心责任之一。社区成员向我们的仓库提交内容,我们这些编辑决定是否合并这些贡献。
让我们看看实际效果。首先,如果我们拿一个普通的Rust社区成员结构体的实例,试图使用一个没有为它实现的方法,我们会得到一个编译错误。然而,如果我们创建一个TWiR编辑结构体的实例,并将其与我们的Rust社区成员结构体实例关联,我们就可以成功调用这个方法。我们只需要戴上正确的帽子。
让我们再考虑一顶帽子。Rust基金会董事会成员的帽子怎么样?我来自西雅图,所以我选择使用一顶小滑雪帽作为我的Rust基金会董事会成员帽子。
好的,让我们再次创建一个新的结构体来表示基金会董事会成员。同样,我们的结构体有一个rust_station字段,但现在我们还有一个director_type字段来表示这种类型。让我们引入另一个Rust概念,使用一个枚举,包括两种类型的基金会董事:公司董事和项目董事。如果你想了解更多关于为什么董事会上有这两种类型的董事,请查看Sage Griffin今天晚些时候的”Rust基金会揭秘”演讲。
现在,在我们的代码中,我们有了用结构体和枚举表示的数据,现在我们需要能够用这些数据做一些事情。基金会董事会成员做什么呢?他们参加董事会会议。所以让我们在另一个特征中捕捉这种行为 - 董事会会议特征。我们在这里使用特征而不是直接在结构体上实现它,是因为董事会会议虽然包括基金会董事,但也包括一些基金会工作人员,所以我们可能想为多种类型实现这种行为。这个特征将包含一个attend_board_meeting方法,它再次有一个默认实现。
回到我们的董事会成员结构体,让我们为RF董事会成员实现董事会会议特征。现在,所有董事会成员结构体的实例都可以参加董事会会议了。再一次,让我们看看实际效果。
让我们从一个普通的Rust社区成员开始,一个没有戴上基金会董事会成员帽子的人。如果我们试图使用attend_board_meeting方法,我们会得到一个编译错误,因为我们的特征没有为Rust社区成员结构体实现。然而,如果我们使用与该Rust社区成员关联的董事会成员结构体的实例 - 再次戴上正确的帽子 - 那么它就会成功编译。
当你戴着多顶帽子时,很难知道在什么时候应该戴什么帽子。当你不确定应该戴哪顶帽子时,答案总是选择最适合当前情况的那顶。例如,当我审查This Week in Rust的拉取请求并决定是否合并它时,我不能戴着我的董事会成员帽子做出那个决定。我作为董事会成员的感受不能用来决定This Week in Rust应该包含什么。我必须戴上我的编辑帽子,根据我们编辑设定的标准来评估拉取请求,不管我在董事会成员的角色中可能对某事有什么感觉。
这就引出了另一个问题:如果我们的两顶帽子之间发生冲突怎么办?例如,如果有人向This Week in Rust提交了一篇批评基金会某个行动或倡议的文章怎么办?在存在冲突的情况下,引入另一个没有那种冲突的人是至关重要的。在这个非常具体的例子中(这种情况确实发生过),我需要引入另一个编辑或几个编辑来做出那个决定。从个人角度来说,放手一个我感觉很有主导权的决定可能真的很难,但对项目最好的做法是让没有冲突的人做出那个决定。
在像Rust这样大的生态系统中,我们每个人都戴着非常不同的帽子。我们中任何一个人或任何一个群体不可能时刻了解Rust世界中发生的一切。这意味着我们通过广泛理解的渠道进行有效沟通是至关重要的。这对Rust的成功不仅至关重要,对其生存也至关重要。
例如,回到我们的代码比喻,让我们创建一个新的Rust社区成员结构体实例。让我们为一个名叫Ferris的新社区成员创建一个实例。假设Ferris有一些关于Rust基金会的想法或反馈,想要与基金会工作人员交谈。好,让我们先创建一个工作人员的例子。
首先,我们为Sage创建一个Rust社区成员结构体的实例,我们在这次会议开始时都已经见过Sage了。然后,让我们创建一个基金会工作人员结构体,我们可以将其与这个Rust社区成员关联。再创建一个与Sage Rust社区成员关联的这个结构体的实例,这个实例的职位是社区倡导者。
此时,我们有一个普通的Rust社区成员,也有戴着基金会工作人员帽子的Sage Rust社区成员。现在,Ferris需要一种与Sage沟通的方式。我刚刚意识到我为Sage用了一个小厨师帽,而在这个会议中心的另一层正在举行一个厨师会议。
Rust社区和基金会工作人员之间正式沟通渠道之一是通过Rust语言Zulip聊天。由于这种聊天行为将在不同的结构体之间共享,让我们创建一个Rust Zulip特征。在这个特征中,让我们创建一个log_onto_zulip方法,然后是一个send_message方法,它接受一个字符串参数来表示消息。
现在我们有了特征,让我们在Rust社区成员结构体上实现它,这样Ferris就可以使用它了。我们还需要为基金会工作人员结构体实现它,所以让我们继续实现它。当我第一次学习结构组合时,这对我来说有点困惑,因为我来自传统的基于继承的语言。即使这两个结构体是相关的,我们仍然需要为这两个不同的结构体实现相同的特征。
现在这个特征已经为两个结构体实现了,我们可以创建一个在Zulip上通信的函数,并使用特征约束来确保传递给它的任何类型都已实现Rust Zulip特征。太好了,现在他们俩可以在Zulip上自由交流了。
Zulip远不是我们作为一个社区互动的唯一地方。我们还在GitHub上进行大量交流。这是我与社区其他成员互动的主要场所之一。还有官方的Rust Discord服务器。当我学习Rust时,Rust Discord给了我巨大的帮助。无论我问的问题多么基础,没有人叫我菜鸟,他们都以支持的方式回答了问题。即使到今天,当偶尔出现问题时,它仍然对我有帮助。
还有Rust论坛,我发现它对查找关于这门语言的历史信息和当前信息都很有用。当然还有其他渠道。
有这么多种沟通方式很好,但有时这使得很难知道在什么情境下使用哪个接口。什么该放在Zulip上,什么该放在Discord上,什么该放在GitHub仓库里等等。谁来决定这些呢?
决定在给定情境下使用什么接口的人,是那些戴着最适合该情境的帽子的人。每个团队、每个小组、每个组织都要决定什么场合最适合他们的特定需求,我们所有人都需要尊重这一点。
话虽如此,在某些地方进行沟通时我们需要格外谨慎。我认为使用这些地方进行沟通就像在Rust程序中使用unsafe块。unsafe并不意味着你不应该做某事。例如,当我在开发一个crate并想实现一个C API时,我就会使用unsafe块,因为那是我想要的唯一实现方式。所以它并不意味着你不应该做某事,而是意味着你在做的时候需要格外小心,因为你可能无意中引入未定义行为。
从沟通的角度来看,我们需要最小心引入未定义行为的地方是在社交媒体上讨论事情时。对我来说,社交媒体是一个需要在unsafe块中使用的unsafe函数。再说一次,unsafe并不意味着你不应该做某事。我当然不会告诉你不应该在社交媒体上谈论Rust。有时候这是完成你需要做的事情的唯一方式。unsafe只是意味着你必须在做的时候格外小心。
有时候,即使参与讨论的人只有良好的意图,社交媒体上的讨论也可能被真正有恶意的人注意到。在过去的一年里,我们不幸地看到了这样的例子,社交媒体上的对话变得激烈,被Rust社区以外的人注意到,然后他们以巨魔群的形式降临。这些巨魔群用恶毒的骚扰和威胁淹没了我们社区的成员。没有人应该因为一场巨魔群而遭受攻击。
译者注:
“Troll swarms”（巨魔群）是指一群在线用户（通常是恶意的）集中攻击或骚扰特定个人或群体的现象。这个术语中的特点如下：
“Troll”（巨魔）：在互联网语境中，指故意在网上发布煽动性、挑衅性或离题内容以引起他人反应的人。
“Swarm”（群）：暗示大量trolls同时行动，就像昆虫群那样集中攻击。
就像我们在Rust中编程时需要非常小心使用unsafe块编写程序的意外后果一样,我们在社交媒体等场合讨论事情时也需要非常小心意外后果。
在我结束这次演讲时,我希望你们能记住这一点：无论你在Rust社区戴着什么帽子,甚至如果你觉得自己还没有戴上任何帽子,你都是受欢迎的。你是需要的。你是有价值的。我们很高兴你在这里。
当你参加这次会议时,我希望你能与其他人交谈,无论是面对面还是在Discord上,了解他们在Rust社区戴着什么帽子。也许你会发现一些让你感兴趣的东西。有很多不同的方式可以参与进来。当你找到一顶你喜欢戴的帽子时,我希望你能写下来,并将其提交给This Week in Rust。因为那意味着我可以戴上我最喜欢的帽子,欢迎你加入我们。
谢谢大家。
原文链接: https://dashen.tech/2018/07/13/RustConf-2023-Rustacean-Community-Interfaces-A-Tale-of-Many-Hats/
版权声明: 转载请注明出处.