三入三废的Rust的入门 前言 Rust 连续多年在 Stack Overflow 的"最受喜爱语言"调查中排第一，但同样有名的还有它的学习曲线。我从 2023 年开始，前后三次打开 The Rust Book，又三次关上——直到最近才终于摸到了一点门道。这篇文章记录我反复放弃又重新开始的过程，以及这次觉得终于"入门了"的几个关键点。 为什么要学 Rust 对我个人而言，有几个朴素的动机： 写过高并发服务被 GC 停顿坑过：Rust 无 GC 的内存安全保证，解决了"要性能还是安全"的两难 Cargo 生态太舒服了：一个命令搞定构建、依赖、测试、发布，比 C++ 的 CMake 地狱友好太多 类型系统的安全感：Rust 的类型系统让很多 bug 在编译期就被拦截，而不是半夜被报警叫起来排查 三次放弃的心路历程 第一次：所有权直接劝退 第一次翻开 The Rust Book，前三章还挺舒服——语法挺现代的，变量默认不可变，模式匹配很优雅。到 第四章 所有权那里，一切戛然而止。 fn main() { let s1 = String::from("hello"); let s2 = s1; println!("{}", s1); // 编译错误！ } 我真的愣住了，心想"凭什么赋值一下就把原变量废了？"——后来才明白这是 Rust 所有权转移（move） 的核心，目的是在编译期就标记哪些内存只能有一个 owner。当时理解不了这套心智模型，就放弃了。 第二次：生命周期劝退 几个月后又鼓起勇气再读，这次咬着牙过了所有权。但到了生命周期标注，再次崩溃： fn longest<'a>(x: &'a str, y: &'a str) -> &'a str { if x.len() > y.len() { x } else { y } } 'a 是什么？为什么需要手动标？编译器不是能推导生命周期吗？——实际上编译器有时候确实搞不清返回的引用到底来自哪个参数，需要人工标注来约束。但当时的我不理解背后的借用检查器逻辑，只觉得是在和编译器打架。 ...

绿导师：“数据即知识，压缩即智能"的个人解读 这句话从哪里来 这句话出自 Marcus Hutter（人称"绿导师”），他是 AIXI 理论模型的提出者，Hutter Prize（压缩人类知识竞赛）的发起人。原话大致是：“data is knowledge, compression is intelligence”。 第一次听到这句话时我觉得它很玄学——压缩不就是 zip 吗，跟智能有什么关系？后来慢慢理解了其中的深意。 压缩的本质是找规律 压缩算法做的事情很简单：找到数据中的冗余，用更短的符号表示它。 举个例子：字符串 "ABABABABABAB"，可以压缩为 "AB×6"。这个压缩过程的前提是算法"发现"了重复模式 "AB"。 这和智能有什么关系？智能的本质就是发现模式。 人类看到天空乌云密布就知道要下雨，这不是玄学，是因为我们的大脑从过去的经验数据中"压缩"出了一个模式：乌云 → 下雨。 从信息论的角度看 Shannon 的信息论告诉我们：信息量 = 不确定性的大小。一个完全随机的序列无法被压缩，因为它没有规律。而一个能被高度压缩的数据集，说明它内部存在很强的规律性。 这和机器学习的训练过程完全一致： 模型训练 = 从海量数据中提取共同模式（压缩） 模型推理 = 用提取的模式来解释或预测新数据（解压） GPT 系列模型本质上做了一件事：用几十亿个参数将互联网上的文本压缩成了一个"世界模型"。参数越少、效果越好 = 压缩率越高、失真越低。 Hutter Prize 的启发 Hutter Prize 的规则很简单：谁能把 1GB 的维基百科文本压缩得最小，谁就拿奖。这背后是一个哲学假设：压缩能力 = 理解能力。 一个只会做字符替换的压缩算法（比如 gzip）无法真正压缩维基百科到极致，因为它不理解语义。但一个理解"中国首都 = 北京"这个知识的人（或 AI），看到文中第三次出现"中国的首都是北京"时，就可以用极短的引用来代替。 这和人类学习知识如出一辙：学得越透彻 = 能用越少的关键概念复述整个知识体系。 对我日常工作的启发 写代码本质上也是一种压缩。 好的抽象就是对重复模式的压缩——把常见逻辑提取成函数、类、模块，本质上和 zip 做的是同一件事。DRY（Don’t Repeat Yourself）原则就是编程中的压缩原则。 反过来看，如果我们发现某个模块难以抽象、代码总是重复——那可能是因为我们对业务模式本身的理解还不够深，还没能找到那个可以被压缩的规律。 小结 “压缩即智能"不是一个可以写在简历上的实用技能，但它提供了一种理解 AI 和智能的元视角：智能 = 从经验中学习规律 = 压缩数据中的冗余。这个框架虽然简化了问题，但用来思考学习和知识体系构建，还是挺有用的。

Podman与Docker的架构分析 为什么要关注这个对比 Docker Desktop 从 2021 年起对大型企业收费，加上 Docker 本身的一些架构问题（守护进程单点故障、root 权限依赖），促使很多人开始考虑替代方案。Podman 是目前最成熟的替代者。 我从一个日常使用容器的开发者的角度，聊聊这两个工具的核心差异。 架构差异 Docker：守护进程模型 用户 → docker CLI → dockerd（守护进程）→ containerd → runc → 容器 Docker 的核心问题是所有操作都经过一个 root 权限的常驻守护进程（dockerd）。这意味着： dockerd 挂了，所有容器的管理能力就没了 dockerd 本身是 root 权限运行，是一个安全风险面 日志、网络等资源都受 dockerd 控制，难以用 systemd 等标准工具管理 Podman：无守护进程模型 用户 → podman CLI → 直接 fork → conmon → runc → 容器 Podman 没有后台守护进程。每次运行容器时，Podman 直接 fork 出一个子进程，通过 conmon 作为容器的监控进程。这意味着： 没有单点故障 可以用 systemd 管理容器（配合 podman generate systemd） 天然支持 rootless rootless 容器的实际意义 Docker 也有 rootless 模式（Docker 19.03+ 引入），但是通过用户态模拟实现的，存在一些限制。Podman 的 rootless 模式从一开始就是核心设计目标，实现得更加成熟。 ...

初次使用Vibe Coding 带来的思考与反思 什么是 Vibe Coding Vibe Coding 是最近流行起来的一个说法，大致意思是：对着 AI 编程助手描述你想要的功能，然后让它生成代码，不满意就继续对话调整——整个过程像是在跟代码"聊天"，而不是在写代码。 今年尝试了 Cursor 和 Claude 的编码助手之后，对 Vibe Coding 有了切身体验，这篇是我的个人反思。 直观的感受：高效与不安并存 第一次用 AI 生成一个完整的 CRUD 接口时，我的感觉是震撼的——几行自然语言描述，几十行代码自动生成，import 全都正确，异常处理都帮我写好了。前后不到一分钟。 但紧接着就是一种隐隐的不安：这段代码真的正确吗？每一行的意图我都理解吗？如果有隐蔽的 bug，我能发现吗？ 这种不安感其实很准确——AI 生成的代码看起来都对，但偶尔会在一些意想不到的地方出问题： 生成的 SQL 没考虑到索引设计，在大表上会跑全表扫描 错误处理写得很"教科书"，但缺乏对业务异常场景的判断 并发场景下的代码往往有微妙的线程安全问题 Vibe Coding 最适合做什么 经过一段时间的实践，我觉得 AI 编码助理在以下几个场景中确实非常高效： 1. 样板代码（boilerplate） CRUD、DTO 转换、配置解析、API 接入——这些重复性高、逻辑性低的工作，AI 完成得又快又好。我甚至不需要检查太多细节。 2. 探索不熟悉的技术栈 想快速试一下某个框架的用法？让 AI 生成一段 demo 代码，比翻文档快得多。它可能不是最佳实践，但至少能让你快速看到效果。 3. 单元测试编写 这是我觉得 AI 最有价值的用途之一。给定一个函数，让 AI 生成各种边界条件的测试用例，它往往能覆盖到一些你没想起来的场景。 4. 代码审查辅助 把一段代码贴给 AI，让它分析潜在问题（安全漏洞、性能隐患、代码异味），作为人工审查的补充，效果意外地好。 Vibe Coding 最不适合做什么 1. 核心业务逻辑 涉及复杂的业务规则、状态机、事务处理时，AI 容易出错。而且错误的代价很高——测试不一定能抓到所有边界条件。 ...