编译也是一种测试
文章主要讨论了关于Rust编译时长的问题。尽管已有并行前端、Cranelift后端和lld链接器等技术在改善Rust的编译效率，但由于一些根本性限制，其编译速度仍可能无法达到所有人的期望。 然而，作者指出有一种新的看法：由于Rust能在编译过程中捕获诸多问题，因此编译实际上可以视为你测试程序的一部分。这就是说，程序中任何规定的接口（如函数的签名、特性、变量类型）在编译时都相当于执行了一次小型的单元测试，而任何编译错误都可以看作是测试的失败。
原文链接 https://kobzol.github.io/rust/2024/02/04/compiling-rust-is-testing.html
reddit 上r/rust订阅增长
r/rust 现在已经增长到 271k 订阅者, 已经与 r/cpp 一道登上了系统编程语言reddit订阅人数的第一阶梯，领先于 r/go（236K），以及远远领先于 r/C_Programming（154K），r/Zig（11.4K），r/ada（8.6K）以及 r/d_language（5K）
原文链接 https://twitter.com/AstraKernel/status/1754020550434009393
Let futures be futures：关于Rust异步并发模型的再思考
这篇文章讨论了Rust语言中 future 的抽象概念，以及它在并发操作中的作用和相关争议。从2010年开始，出现了探索并发新方法的语言复兴期。在此期间，开发出的一种实现并发操作的抽象是"future"或"promise"，这允许程序员在控制流中使用它。基于此，引入了"async/await"语法糖，使得future能够被整合进线性控制流中。这种方法已被多种主流语言采用，但也存在争议。
文章重点介绍了两篇优秀的文章，它们分别代表了对"future"的争议的两侧。一篇是Marius Eriksen在2013年写的，主张"future"提供了和线程不同的并发模型。它列出了一些使用"future"的优点，如类型的区分、多种组合方式、直接表达逻辑等。另一篇是Bob Nystrom在2015年的文章，批判这种区分异步函数和同步函数的做法，认为这给程序员带来了麻烦。 文章作者倾向于Eriksen的观点，认为"future"作为并发的模型优于传统线程。他探讨了Rust是如何采纳这种模型的，并希望建立一个更好的async Rust。
原文链接 https://without.boats/blog/let-futures-be-futures/
探究Rust并发编程的强大功能
Rust通过线程、消息传递和共享状态实现多任务并行处理能力，其所有权和类型系统在编译时帮助开发者避免常见的并发错误。
本文给出了一些示例, 包括多线程执行、通道消息交换和共享数据的线程安全操作，展示了Rust在保障并发安全性的同时，如何有效地管理并行任务。这些特性让Rust成为开发高性能、可靠系统的理想选择
原文链接 https://www.thealphadev.com/2024/02/unraveling-power-of-concurrency-in-rust.html
Slint 1.4版本发布：新增外观样式及API改进
Slint 1.4版本带来了全新的Cosmic外观样式和许多生活质量改进。
- 新增了模仿System 76的Pop!_OS风格的Cosmic样式。
- 新的API响应了用户反馈，增加了许多先前缺失的功能，如触摸区域的双击回调、配色单件的自定义控件适配，以及通过新的set_fullscreen(bool)函数以编程方式显示全屏窗口等。
此外，Slint引入了用于JavaScript API的二进制包，现在在macOS、Windows、和Linux上无需从源代码编译即可安装Slint，加快了npm安装步骤。
Android端口进展顺利，已支持虚拟键盘输入；LinuxKMS后端也新增了显示旋转支持。
开发体验也有所改进：if语句中的括号现可省略，自动补全更贴合开发者标识符选择，编译器优化生成更高效的输出，提高了应用程序的编译速度
原文链接 https://slint.dev/blog/slint-1.4-released
--
From 日报小组 BobQ, FBI小白
