一篇关于C++, Rust 和 Zig 在内存安全上的主观观点文

作者比较了三者在内存安全上的观点，认为Zig在语言复杂度和内存安全上取得了一个比较好的平衡。

小编观点：在内存安全这件事情上，世界上只有两种语言，一种是Rust，另外一种是其它语言。

https://medium.com/@shyamsundarb/memory-safety-in-c-vs-rust-vs-zig-f78fa903f41e

比较：Leptos，Dioxus 和 Next.js 之间的比较

一个前端开发者对这三个框架进行了用户体验层面的比较，对想用Rust做前端开发的人讲比较有价值。

https://codethoughts.io/posts/2024-07-05-static-spas-exploration-of-leptos-dioxus-and-nextjs/

关于Sematic Version的讨论

当我们谈论软件版本号时，我们通常会遵循一种标准的格式，例如 MAJOR.MINOR.MICRO。这些数字用于表示软件发布的不同版本。而**语义化版本控制（Semantic Versioning，简称SemVer）**是一种试图为这些版本号赋予更多含义的方法。然而，实际应用中，SemVer 经常被误用，其承诺未能兑现，对维护者和用户都带来了一系列意外后果。

让我们来看看一些关键点：

1. 版本号的目的：版本号的主要目的是能够判断一个实体的哪个版本比另一个版本更新。在软件包的上下文中，我们将版本号解释为由整数元组组成的序列，用点号分隔，从左到右具有优先级。例如，版本 2.0 比 1.10.0 新，而后者又比 1.9.42 新¹。

2. SemVer 简介：SemVer 的格式为 MAJOR.MINOR.MICRO，并承诺只要 MAJOR 不变（即不进行主要更新），就不会破坏现有功能，用户可以无顾虑地更新依赖。但如果 MAJOR 是零，那么维护者可以随意更改一切。然而，实际上，SemVer 的应用存在问题，其承诺难以实现，给维护者和用户带来了不少麻烦。

3. Hyrum's Law：Hyrum Wright 提出了一条基本的软件开发法则：“只要有足够多的 API 用户，不管你在合同中承诺什么，系统的所有可观察行为都会被某人所依赖。” 这意味着，即使维护者非常谨慎，也无法预测更改会如何影响用户。因此，版本 3.2 是否与版本 3.1 兼容，很难确定。尽管你的单元测试表明软件“基本上工作正常”，但如果在 3.1 和 3.2 之间有意义上的行为变化，你肯定会更改测试用例¹。

总之，SemVer 只是版本号的一种表达方式，它传达了包作者的意图和目标。然而，用户应该保持现实，不要对版本号产生过高的期望，因为软件的变化总是会影响到某些用户。

https://hynek.me/articles/semver-will-not-save-you/

--

From 日报小组 Mike

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区