#Rust
SAP内部，貌似对Rust重度使用，所以他们对自己项目里使用到的项目upstream提了很多改进方案，比如：

对async-trait：https://github.com/dtolnay/async-trait/pull/189
对openraft：https://github.com/datafuselabs/openraft/pull/220

这两个老哥貌似都是一起在SAP内部为一个项目work的。

#Rust

这篇文章把Rust里future、pin等的原理都讲解的很好，作者的这一系列使用Rust来写OS的文章也很好：

https://os.phil-opp.com/async-await/

#Rust
rust版本的leveldb实现：

https://github.com/Fullstop000/wickdb

#Rust
《pretzelhammer's Rust blog》

https://github.com/pretzelhammer/rust-blog

其中的《Tour of Rust's Standard Library Traits》有中文翻译：
https://github.com/pretzelhammer/rust-blog/blob/master/posts/translations/zh-hans/tour-of-rusts-standard-library-traits.md

#Rust
Rust中，内存管理是很重要的一块，这个项目总结了不同方式下应该使用哪些container来管理内存：

Rust Memory Container Cheat-sheet

#Rust

Rust里面的宏有点难度，以至于要单独拿出来写一份专门的教程了：
《The Little Book of Rust Macros》

#Rust
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8aebac82933ff1a7c8eede18cab11e1115e2062b

Rust for Linux已经被合并到了Linux内核代码的主干分支了。

#Rust
《The What and How of Futures and async/await in Rust》

哥们真是硬核，开着视频敲代码生生讲了4个小时，但是我自己看下来感觉这样的效率对观众来说可能并不算高：

* 不能搜索里面的关键字，这导致回头想精准得看其中的一部分比较麻烦
* 听力问题可能有一些表达听不懂（清楚）
* 中间有一些表达作者感觉还在酝酿更好、准确的表达，这些时间被浪费了。

所以我感觉还是写成文档会更好一些，现在我把“写文档”类比成内存里的数据落盘，而数据在落盘之前都会被规整成一个更合理的格式的。

#Rust
Rust Analyzer 作者亲自教你如何 hack 它：https://www.youtube.com/watch?v=I3RXottNwk0&feature=youtu.be

原推：https://twitter.com/RustTalk/status/1582916057093656576

#Rust
Rust死灵书（《The Rustonomicon》） 的 中文翻译版，翻译者应该在字节从事Rust基础架构工作。

#Rust
早年学C++的时候，觉得如果只推荐一本C++的书，那一定是《Effective C++》，这本书总结了C++里最重要、常见的一些知识点，事实上我甚至认为任何领域都需要这样一本总结出最常见知识点的书。

如今网上有人写了一个《Effective Rust》出来，也是类似的思路。

#Rust
JetBrains发布独立的Rust IDE RustOver：《Introducing RustRover – A Standalone Rust IDE by JetBrains》，之前要在JetBrains系的IDE写Rust都是走插件的路线，现在终于出了一个独立的产品。

像JetBrains这样专业做开发者工具（IDE）的公司，必然掌握了很多开发者的统计数据，衡量一个语言的流行度，有不同的数据维度，比如社区的活跃度、开源项目的数量、搜索的数量等等。商业开发工具的数量、质量也应该是一个维度，因为商业公司要为之开发新产品，这背后肯定需要数据的支撑才行。

#Rust
我司xuanwo的一篇文章《Rust std fs slower than Python!? No, it's hardware!》，还登上了hacker news的热门榜。
中文版本：《Rust std fs 比 Python 慢！真的吗！？》

PS：鄙视某些把本文题目篡改称”Rust比Python慢“的自媒体，真是为了点击率什么题目都能想出来。

#编程语言
#Rust

以前会争论类型标识符，应该放在变量前面还是后面好。

除了美感这种偏主观的判断以外，我在学了一点PLT皮毛之后，有一个新的视角：

类型标识符在变量前面的语言，大多是没有类型推断的，因为放在前面，所以无法省略，就是说：必须在声明这个变量的时候就（由程序员）确定变量的类型。这也有例外，比如C++后面引入的auto关键字，相当于给原先的语法打了一个“补丁”，通过这个关键字声明的变量就能支持类型推断。

反之，放在变量后面的类型标识符，因为是可以做到省略的，省略的时候就是类型推断发挥的空间了：推断出最适合的类型出来；同样也有例外，比如Go就不支持类型推断。

比如附图中的这段Rust代码：
同样的let a = 1，在两个上下文（context）里推断出来的是不同的类型：上面的代码由于没有别的信息，所以就选了i32类型；下面的代码由于要和已经声明为u64类型的b相加，所以推断出来a的类型为u64。

支持类型推断（type inference）的语言，（应该都）要做到类型安全（type safety）。比如：不能允许两个变量的数据，操作之后出现溢出等情况。

综上，我更喜欢支持类型推断、类型安全的语言。

Roman Elizarov（Project Lead for the Kotlin Programming Language）的一篇文章《Types are moving to the right》中也提到，21世纪之后才出现的编程语言，很多都是把类型标识符放在变量后面了，Go、Rust、Scala等。