Month: November 2025

Rust 项目一旦增大，用 cargo new demo 创建的单一包，单个 src/main.rs 的项目组织方式不能满足需求了

$ cargo new demo
$ tree demo
demo
├── Cargo.toml
└── src
          └── main.rs

比如至少要一个 src/lib.rs 文件吧，复杂些还需在  src 目录中创建模块层次的目录; 更大型项目还要在 Package 上边创建 Workspace。

这里就引出了 Rust 项目的几个概念，即 Package, Crate, 模块，以及 Workspace，再就是如何在代码中引用不同 Package, Crate, 模块中的资源要用到路径。

比如这个最基本的 demo 项目中

1. Package: 一个可以构建，测试和分享 Crate 的单元，它可包含可选的 lib crate 和多个二进制 crate 项。  demo 就是一个 Package，src/main.rs 就是一个二进制 crate, 如果有 src/lib.rs 就是一 个 lib crate, 它只能有一个。其他的放在 src/bin/* 中的多个 *.rs 文件是一个个独立的二进制 crate，它们会被编译成多个执行文件。下面将会演示。
2. Crates: Rust 编译器编译的最小单位。每个  crate 会输出一二进制文件或 lib
3. Module: crate 内部的代码层次组织结构，由 mod xxx; 或  mod xxx { ... } 定义
4. Path: 访问 module, 函数，类型等和路径，分绝对路径(crate::foo::bar::baz, lib::something::func)与相对路径(self::foo::bar, super::baz)

阅读全文 >>

写了几天 Rust 之后，不光被它的 Ownership, Lifetime 折磨的死去活来，还碰上个奇怪的错误处理方式。如果让程序员在 Java, C/C++, Python, Ruby, Scala, Go，甚至是 Lisp 语言之间换着干活，那还都不是难事，但是拉个人去弄 Rust 就会要人命了。

有垃圾回收的语言基本就是想怎么写都成，程序运行时也不会出太大的事，当然性能是个妥协; 像 C/C++  自己管理内存的语言写出来的程序通过编译也容易，只是执行时很可能会有内存泄漏或地址越界。而选择号称性能与安全兼备的 Rust 语言的话，按照正常思维逻辑写出来的代码能通过编译就是最幸福的事。碰到关于 Ownership, Lifetime 之类的编译问题很多时候当前的 AI 也无解。

所以现在还能用 Java, Python, C# 等写代码是个幸福的事，这种时光应该好好的珍惜。换个角度来想，如果能掌握 Rust 那还怕别的语言吗？

就算能侥幸的应付 Ownership, Lifetime 的问题，Rust 错误处理方式也会让人抓狂，起初大量的用 unwrap() 忽略错误，用多了也会觉得不是一回事。

主流的语言都是采纳 try/catch 方式处理异常方式，异常在栈中向上传播，想在哪一层捕获异常都行，所以才可能在某处集中的处理异常，也让程序结果返回与异常处理得已分离。

有一个视频 什么是正确的错误处理方法【让编程再次伟大#21】介绍了各种编程语言错误处理方式的历史发展，视频博主十分推崇 Rust 的结果错误放 Result  的方式，觉得像  try/catch 那种能够实现关注点分离的方式是便宜了程序员，只有返回 Result<T, E> 的方式才能强制程序员步步小心。那何不让 try/catch 全部抛出 Checked 异常，然而事实是 Spring 框架把许多 Checked 异常转换成了 Unchecked 异常，能程序员处理更方便，且能集中处理异常。

阅读全文 >>