「嵌入式Rust」Rust对Arduino支持进展调查
#arduino
因为Arduino使用的是AVR微控制器，但Rust目前还未支持AVR。但Rust嵌入式开发组已经有计划支持AVR。
感兴趣的朋友可以关注此issues： AVR support
目前也有一个avr-project GitHub项目组独立fork了Rust，提供了对AVR的支持。在官方Rust未支持AVR之前，可以使用这个，看上去还非常活跃。
Serverless HTTP
#serverless #aws #lambda
该文作者探索aws lambda平台的无服务器HTTP应用，并编写了一个crate，叫做lando，它以http crate为核心接口，以lambda为部署目标，来部署API网关。本文就是对lando的介绍。
Withoutboats眼中的Rust 2019：组织债务
#rust2019
官方核心团队成员无船同志在本文中阐述了他对Rust 2019的看法。该文主要谈到了组织治理，Rust自身作为一个开源项目，也可以把它看作一个成长中的初创「产品」，不免会遇到成长之痛。作为Rust团队的内部成员，无船同志以他的视角来分析了Rust组织内部产生的问题，对于我们也是一种警示和学习。
首先，他肯定希望Rust会有更多的技术改进，而且他也会为之付出精力。但是，他认为2019最重要的问题不在于技术改进，而是组织债务（Organizational Debt）。
什么是组织债务？它是和技术债务平行的一个名词。我节选一段infoq文章中的阐述： “组织债务”是在公司层面上是与技术债务平行的。如果技术债务是软件中妨害维护的问题，那么组织债务就是妨碍组织在日常运转中流畅运作的问题。他列举了如下几个组织债务的例子：
- 解决同一个问题，不同的部门都有自己的工具和方法，这使得主管们很难看到相似之处，以便解决公司层面的问题。
- 经理们创建的过程或实现的软件解决方案在当时看来似乎是个不错的注意，但却没有消除问题产生的根本原因，长期来看，最终造成了更多的问题。
- 由于时间特别紧，团队决定“本次”以一种并不是最理想的方式完成一项任务。但是，那种方式后续被重复使用，因为没有人记得第一次原本是打算当作一种一次性方案。
更通俗一点的描述：
所谓的组织债务就是初创公司为了「把事情搞定」而做出的所有人事/文化妥协。这些债务会在一定阶段爆发，比如公司融到了新一轮的钱/公司的战略方向调整/公司的人事扩张。这在一定程度上比「技术债务」更难处理，毕竟「技术债务」你面向的是工程/代码，而「组织债务」面向的是人。
组织债务影响的是能否可持续发展的问题。
无船同志认为，Rust项目在过去的几年里，一直想创业公司一样成长，虽然有很多好的方面，但也有一些糟糕的问题，如果这个项目想长期地维持下去，必须真正处理到目前已经积累起来的组织债务。以下是无船同志罗列出来要解决的问题：
一 使用GitHub issues来讨论设计就像是从消防栓里喝水
看这个图片感受一下
无船同志统计了关于Pin API讨论的issues中评论数，一共有770条评论，还不算是reddit、irc或discord中的聊天记录。Rust虽然是他的全职工作，但是他发现还跟不上团队内其他人的设计讨论。
其实Pin API虽然重要，但最终也是一个比较小的标准API添加，其中并没有包括关于异步、生成器或Futures的讨论。当这个主题高达770条评论的时候，谁有心思看完呢？包括参与评论的人也是，而且经常要对一个比较模糊的概念重新进行解释，这样每一条加入讨论的评论，都算是一种债务。更糟糕的是，将这些讨论再分解为更多的子问题，也无法解决问题。无论他们创建多少Github issues，似乎每一个issue都会变得越来越长。
所有的这些讨论都会带来下面几个负面后果：
- 对于那些在讨论中想推动共识的人来说，会变得筋疲力尽
- 对于真正有新见解的用户来说，参与变得更加困难。
- 新加入讨论的新人，和已经知道大部分上下文的人之间会造成冲突
RFC流程没有达到它应有的效果。在改革这个过程之前，无船同志对于发起新的共识讨论（比如提出一个语言的新特性）感到非常不满意。
二 项目内部并没有顺利地协调
为了保证连贯的用户体验，Rust需要在不同的方面拥有一致的设计愿景。在过去，团队成员低于30人时，共享愿景可以自然地在整个项目中传播。但是随着团队规模的增加，现在这种愿景在团队中共享起来就遭遇了很多问题。现在需要一个积极的专门用来处理和设计相关决策信息、模式和框架了。今年无船同志就遇到了因为没有统一的指导方针而发生的分歧的问题。所以现在可以考虑重新核心团队的组织，并认识到团队之间协调的重要性。
三 团队正在经历成长之痛
Rust项目管理主要由负责项目的各个领域的各个团队执行。无船同志是其中三个团队的成员。他感受到了这三个团队内部的成长之痛：
- 对团队的成员分解为更小的团队来分解任务，比如工具和基础设施团队已经分解了五个小团队，这是为了解决任务模糊的问题，便于各负其责。但是分解小团队可能并未解决具体的问题。
- 与此同时，团队常常会没有方向感，没有特定的目标。
- 随着团队成员的增加，成员的日程安排、同步协调等方面都不是很有效。
- 并且团队的共享知识也很难转移给新来的成员，因为还没有有意识的来执行这个事情。
四 工作组需要工具包
需要将工作组的工作方式抽象为其他人可以使用的标准模板或流程，当然更重要的是需要有协调和领导力的人进入工作组。
五 社区管理让人身心疲惫
需要一个高于社区行为准则的标准来规范参与Rust项目的工作，用于强制性地进行专业意见的交流，让沟通更加高效。社区的行为准则只是规范社区内成员随意互动的标准。
六 是时候讨论薪酬了
并不是无船同志想涨薪了，而是他看到现在开源社区很多志愿者投入了大量时间但并没有报酬，完全是为了兴趣或学习而进入社区。但很多人应该用一种长远的眼光来看Rust，它在未来会带来就业发展的回报。
但随着生活状态的变化，很多可以推动重要项目的志愿者已经退出，导致Rust的很多工作进展都不太顺利。只有拥有大量空闲时间和信心的人才能作为志愿者大力参与。现在的开源贡献者，其实都是资产阶级中的“无产”阶级。也许成立「Rust基金会」是一个办法。
总结：
在找到解决问题的办法之前，必须先正视这些问题，承认它们的确存在。还清组织债务，只需要重新设计决策过程，重新组织治理结构，建立新的沟通规范，并找到一种方法来将大量资金转向Rust贡献者。
Raph Levien的Rust 2019
#fuchsia
来自Google Fuchsia 团队成员对Rust 2019的期望，也值得一看。
cargo-expand：查看宏展开结果
#macro
serde作者实现的新包，包括声明宏和#[derive]过程宏。
$ cargo expand
是对rustc命令的包装：
$ cargo rustc --profile=check -- -Zunstable-options --pretty=expanded
下沙：Rust+WASM+WebGL实现的游戏
#game #wasm
Rust Analyzer 2019
#ide
关注Rust IDE相关进展的可以看看这篇文章
「小工具」验证代码中内存使用
#memory
QADAPT库可以验证代码中何时分配或丢弃内存。作者写了篇文章，以构建自定义内存分配器为例来讲解如何使用QADAPT库提供的debug_assert!验证代码中内存分配情况。
每日新闻订阅地址：
欢迎通过GitHub issues投稿。
评论区
写评论还没有评论