Rust 把 'pub' 搞错了
Source: Dev.to
Rust 中的 pub 关键字
pub 关键字是 Rust 的访问修饰符，用来使函数、结构体、枚举、特性以及模块等项目在其定义模块之外可访问。从这个意义上，它的行为类似于许多其他语言中的 public。
与 JavaScript/TypeScript 的对比
一个主要区别——尤其是当你来自 JavaScript 时——体现在默认行为上。
在 JS/TS 中，类的方法默认是公开的（除非你使用 # 或 private 关键字显式标记为私有）。其底层假设是大多数类方法应该是可访问的，因此不需要不断在方法签名上添加可见性关键字。可以把这称为 约定优于配置。
Rust 本可以借鉴这种思路，但它走向了相反的方向：默认私有，显式声明为公开。
pub 的视觉噪声
结果是你经常会看到类似下面的代码：
一堆 pub 到处乱飞。
如果默认行为相反，代码可能会更简洁——类似 Rust 处理 mut 关键字的方式。变量默认是不可变的，当你显式添加 mut 时，立刻表明该值以后会改变。这种信号既是心理暗示也是技术提示。
现在，pub 并没有同样的信号作用，因为它随处可见，成为视觉噪声。如果 Rust 选择 默认公开，那么显式标记为 private 就可以像今天的 mut 那样发挥作用。看到 private 关键字会立刻告诉读者：“这有意被隐藏，请不要依赖它。”
换句话说，代码会更像：
“这里的所有内容都应该是可访问的——除了这些特定的东西。”
而不是：
“我们想让这个、这个、这个、这个……都是公开的。”
重要说明：基于模块的可见性
有一点需要纠正，为什么这种比较会显得有点不对称。Rust 的可见性是 基于模块 的，而不是基于类的。在 JavaScript（以及许多面向对象语言）中，可见性主要作用于类。Rust 中，可见性作用于模块，模块充当显式的 API 边界。这意味着 Rust 不仅仅是保护字段和方法——它在保护整个命名空间和架构层次。
因此，“默认私有”并非仅仅是风格上的选择。它强烈鼓励：
- 有意的 API 设计
- 最小化公开表面
- 减少意外的破坏性更改
- 更清晰的不变量所有权
这在为大型、长期运行的系统和库设计的语言中尤为重要。
Rust 在这里错了吗？
可能没有。但可用性（ergonomics）争论是否成立？绝对成立。
Rust 用冗长换取正确性和稳定性，这在语言设计层面上是有道理的，但它确实带来了可读性成本——尤其是对来自 JS/TS 的人来说，公共 API 往往是暗示而非声明的。
这种权衡是否值得，取决于你更看重什么：
- 视觉上的整洁
- 还是毫不妥协的显式性
Rust 显然选择了后者。