Snips（一家做音频识别的创业公司） 出品。在神经网络领域，现在基本已经被 TensorFlow 和 PyTorch 给占了。但是对于移动设备或IoT这些性能受限的设备，还有很多空间可以尝试。TensorFlow组推出了 TensorFlow Lite，微软的 ONNX 看上去也很有前景。一些硬件厂商也推出了他们自己的方案 Android NN API, ARM NN SDK ， Apple BNNS 等等。但是它们都只能满足一些特定领域的需求。
于是就有了 tract。在各个平台的性能评测，性能是 TensorFlow Lite 1.2 倍到 4.2 倍。看得人有点心动。
Deno 是一个 JavaScript/TypeScript 运行时，作者其实就是 Node.js 作者。他觉得 nodejs 生态已经没办法再提高质量了，就创建了这个新项目 deno。下面是 Rafał Pocztarski 的视频分享。
这是官方的 Rust SDK。Couchbase 是一个商业的 NOSQL 数据库。
这篇文章作者非常喜欢 Rust，分析了一下目前 Rust 中的机器学习生态的情况。比如：
最后，作者打赌 Rust 在 ML/DL 领域能大展宏图。进一步的讨论可以进 rust-ml 进行。
目的是研究 parakernel。
用 Rust 开发机器人？好诱惑。
可以在线玩儿：Online Play。
这篇文章详细讲述了这个游戏的技术选型发展过程。目前，它综合使用了：ggez, WASM, itch.io, visuals, AI, campaign, tests 等技术。文章写得非常好，强烈推荐阅读。
问题出在手动实现 Error::type_id 和 Error::downcast 家族函数的交互上。
即将马上发布 1.34.2 进行修补。
主要讲解了如何通过RESP实现一个redis client，并用rust实现了一个简单的demo，目前只实现了set和get命令，可以很方便的添加命令，项目地址如下redis-simple-rs欢迎大家完善。
这个的意思是，以后可以指示 cargo 去本地找依赖包缓存。而不是每次都检查网络了。非常实用的进展。
等等稳定版的发布，到时有使用说明。
听起来好像很厉害？
link 在这里讨论的，现在我来整理一下，下面的都是零开销的抽象：
Option<NonZeroI8>and friends (storing None as 0)不是零开销的部分：
有人总结得好：
zero-cost does not mean no cost, it means no extra cost over manually writting code that does not use the abstraction, but emulates instead.
零开销不是指没有开销，而是指与不用（Rust给出的）抽象而用手动直接模拟实现相比，没有额外的开销。
In general: when Rust has a feature F which implements a programming aspect A, and your program requires implementing aspect A, just picking feature F is typically going to be the right choice; reimplementing A yourself (either in Rust or in C or ...) will not yield better performance
通常来讲：当 Rust 有一个特性 F，它实现了一个编程的方面（解决了那样一种问题） A，现在你的程序要实现方面 A（解决那样一种问题），一般来说，只需要直接拿起 F 使用就对了，你手动重新实现（用 Rust 或 C 或其它语言），并不能带来更好的性能。
C++ implementations obey the zero-overhead principle: What you don't use, you don't pay for [Stroustrup, 1994]. And further: What you do use, you couldn't hand code any better.
-- Stroustrup
C++的实现遵从零开销原则：你用不到的东西，不会为其付出代价。更进一步：对于你用到的东西，你没法再做得更好。
-- Stroustrup
In the case of Rust, this applies even more since most of the optimization is offloaded to the compiler. In other words, in practice it is far easier to write slow C++ than slow Rust. In the case you are describing, tuples are slower because they are implemented above the compiler level and thus optimizations are left to the programmer. In Rust on the other hand, tuples are first-class citizens and they are optimized away by the compiler automatically.
对于Rust的情况来说，编译器会承担大部分的优化工作，所以在这方面（相对于C来说）走得更远。换句话说，**实践中往往更容易写出慢的C代码，而不是慢的Rust代码**。对于你描述的情况，元组慢是因为它们实现在编译器的上面一层，因此优化工作留给了程序员来做。而在Rust中，元组是一等公民，它们会被编译器自动优化掉。
From 日报小组 @Mike
日报订阅地址：
独立日报订阅地址：
社区学习交流平台订阅：