BIT & 42

Rust Unlimited Intro - Three Times Failed

Tue, 14 Apr 2026 00:00:00 +0000

Rust Unlimited Intro - Three Times Failed

Introduction

Rust has topped Stack Overflow’s “most loved language” survey for years, but its learning curve is equally famous. I started and quit learning Rust three times since 2023 before finally getting past the initial barrier. This is the story of that journey.

Why Learn Rust?

Performance & Safety: Memory safety without garbage collection — no more GC pause nightmares or segfaults
Modern Toolchain: Cargo, rustfmt, and Clippy create a seamless build/test/lint experience that makes C++ tooling feel archaic
Type System That Catches Bugs Early: The compiler catches an incredible amount of errors before runtime — fewer 3 AM on-call wake-ups
Growing Industry Adoption: From Linux kernel modules to cloud infrastructure (AWS, Cloudflare), Rust is becoming the standard for systems-level work

Three Attempts, Three Failures

Attempt 1: Ownership sent me running

The first three chapters of The Rust Book felt comfortable — modern syntax, immutability by default, elegant pattern matching. Then Chapter 4 on Ownership hit:

Java还有救吗？

Sat, 14 Mar 2026 00:00:00 +0000

Java还有救吗？

这个问题背后的情绪

每隔一段时间就会有"Java 已死"的讨论。坦白说，Java 确实有让人不爽的地方：代码冗长、启动慢、内存占用大、框架配置繁琐。和 Go 的简洁、Rust 的性能、Kotlin 的语法糖比起来，Java 显得有些老态龙钟。

但我觉得这问题的前提就错了——语言不是用来比的，是用来干活儿的。

Java 真正的竞争力是什么

三个字：生态、人才、兼容。

生态

Spring Boot、MyBatis、Netty、Kafka、Elasticsearch、Hadoop、Flink……几乎所有中间件和基础设施都对 Java 有一流支持。这不是一朝一夕能追赶的。

人才

Java 开发者的存量是其他语言难以比拟的。一个公司如果用 Go 或 Rust 创业，招人的难度和成本都会显著高于 Java。不是每个人都能为技术品味买单。

兼容

Java 的向后兼容性是业界标杆。十年前写的代码今天还能跑，这在一些业务场景中是无价之宝。银行、保险、政务这些行业的系统换代周期极长，Java 的稳定性就是核心竞争力。

Java 这几年的自救

Java 的演进速度最近明显加快了：

Java 17/21 LTS：稳定可靠的新时代基线
虚拟线程（Project Loom）：彻底解决了"一个请求一个线程"的资源瓶颈，不需要再用 WebFlux 写回调地狱
Record 类：再也不用写 getter/setter/equals/hashCode 了
模式匹配 + switch 表达式：语法表达力大幅提升
Valhalla（值类型）：解决 Integer vs int 的装箱地狱，性能进一步提升
Panama（外部函数和内存 API）：告别 JNI 的噩梦

虚拟线程是真正意义上的 game changer——它能在一个 JVM 实例上跑数百万个轻量级线程，与 Go 的 goroutine 正面对标，还不需要破坏现有的 Thread API。

三入三废的Rust的入门

Fri, 24 Oct 2025 00:00:00 +0000

三入三废的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 是什么？为什么需要手动标？编译器不是能推导生命周期吗？——实际上编译器有时候确实搞不清返回的引用到底来自哪个参数，需要人工标注来约束。但当时的我不理解背后的借用检查器逻辑，只觉得是在和编译器打架。

绿导师："数据即知识，压缩即智能"的个人解读

Sat, 20 Sep 2025 00:00:00 +0000

绿导师：“数据即知识，压缩即智能"的个人解读

这句话从哪里来

这句话出自 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的架构分析

Tue, 19 Aug 2025 00:00:00 +0000

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 带来的思考与反思

Wed, 14 May 2025 00:00:00 +0000

初次使用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 容易出错。而且错误的代价很高——测试不一定能抓到所有边界条件。

对计算机各个专业及面向的场景的理解与思考

Sun, 22 Dec 2024 00:00:00 +0000

对计算机各个专业及面向的场景的理解与思考

前言

计算机专业在高校中已分化出十几个方向——计科、软工、网工、信安、物联网、大数据、人工智能……在校时总觉得这些专业各有千秋，毕业后才逐渐体会到，它们之间的界限在工作场景中其实相当模糊。这篇文章是我工作几年后对各专业方向的一些个人理解。

计科 vs 软工：理论与工程的取舍

计算机科学与技术（计科） 偏重底层原理：操作系统、编译原理、体系结构、离散数学。学得扎实的同学，在面对性能调优、内存分析、并发模型这类问题时明显更从容——因为有底层心智模型支撑。

软件工程（软工） 则更侧重重工程实践：设计模式、软件架构、敏捷流程、需求分析。毕业后的软工同学在团队协作和项目推进上往往有优势。

实际工作中两者的界限并不重要。大多数后端/全栈岗位对这两类毕业生一视同仁，最终区分能力的是你能否独立拆解问题、设计实现方案。如果非要区分，需要啃底层（数据库内核、基础设施、编译器、嵌入式）的岗位计科更对口；需要快速交付业务的岗位软工更顺手。

网络工程与信息安全：从通才到专才

网络工程专业的处境有些尴尬——纯网络运维的岗位越来越少，云原生和 SDN 让传统网工的技能包在缩水。但网络基础扎实的同学转 DevOps/SRE 其实有天然优势，因为排查线上问题时，网络层往往是第一层怀疑对象。

信息安全在近五年迎来了爆发。从渗透测试、安全运维到安全开发（DevSecOps），岗位细化程度很高。不过有一点需要注意：安全是一个需要持续投入的方向，漏洞库和攻击手法每天都在更新，比起普通开发岗，它更接近"手艺活"——经验积累的边际收益极高。

大数据与人工智能：热潮下的真实场景

大数据方向 的核心不是 Hadoop、Spark 这些工具本身（它们会更新换代），而是对分布式计算的思维方式——数据分片、shuffle、容错、流批统一。在实际工作中，大部分公司的大数据需求其实是"数据仓库 + ETL + 报表"，真正需要调优大规模集群的场景并没有想象中那么多。

人工智能方向 这两年的人才供给已经远超需求。大多数 AI 岗位的实际工作内容是数据清洗、特征工程、模型调参，能真正从事算法创新或前沿研究的坑位极少。对于大多数公司来说，调个 API、fine-tune 一个开源模型就够用了。如果只是跟风选 AI，不如先问自己：你是喜欢调模型，还是喜欢解决业务问题？ 后者在任何一个方向都能走得远。

物联网：软硬件的交叉地带

物联网是软硬件的交叉地带：嵌入式 C、RTOS、通信协议（MQTT、CoAP）、端侧推理。这个方向的岗位相对分散，大厂有专门的 IoT 部门，中小厂更多是在传统嵌入式开发上叠加联网能力。如果你喜欢可感知的物理世界反馈（点个灯、驱动个电机），这个方向会有很强的成就感。

对我自己的反思

回头看，我觉得专业选择没有想象中那么重要——更重要的是在学习过程中形成的问题分解能力和学习习惯。工作中用到的具体技术，大部分都是现学的。所以比起纠结选哪个专业，不如关注能不能在某个方向上持续深度学习、积累可复用的方法论。

这也是我写这个博客的初衷：记录学习过程中的思考，而不是搬运他人已有的知识。

Neo4j图数据库的使用和常用场景分析

Mon, 24 Jun 2024 00:00:00 +0000

Neo4j图数据库的使用和常用场景分析

图数据库解决了什么关系型数据库做不好的事

关系型数据库用外键和 JOIN 来表达实体间的关系，这在关系层级较浅（一两层）时工作得很好。但当关系深度达到三四层甚至更多时，SQL 的 JOIN 会急剧膨胀，性能断崖式下降。

举个例子：查找"和用户 A 有共同好友的所有用户"——在 SQL 中需要自连接好友表两次，而在 Neo4j 中，这只是一行自然表达的 Cypher 语句。

图数据库的核心优势：关系是一等公民，遍历关系的成本是 O(1)，而不是 JOIN 的 O(n)。

典型使用场景

1. 社交网络与推荐系统

最经典的场景。用户-好友-帖子-点赞-评论构成了一个天然的图。Neo4j 可以轻松查询：

二度/三度人脉
共同好友推荐
基于"购买了 A 的人也购买了 B"的协同过滤
内容传播路径追踪

2. 反欺诈与风控

欺诈行为往往是团伙作案：一群虚假账户共享相似的设备、IP、银行卡。在关系型数据库中检测这种环形关联非常困难，但 Neo4j 可以用路径查询快速发现：

资金环形流转检测
关联人/关联账户网络分析
多跳关联风险传播

3. 知识图谱

知识图谱本质就是实体-关系-实体的三元组。Neo4j 天然适合：

企业知识管理（文档-知识点-部门-项目关联）
智能问答的后端存储
供应链追踪

4. 权限与组织架构

公司组织架构是天然的树/图结构。Neo4j 在处理：

汇报链查询
权限继承
RBAC 角色层级

等场景时比递归 SQL 简洁得多。

5. 网络与基础设施拓扑

CMDB、微服务依赖图、网络拓扑、路由分析——这些都是图结构的天然应用场景。用 Neo4j 存储后，可以通过路径查询快速回答"服务 A 宕机会影响哪些下游"这类问题。

Cypher 基础语法感受

Cypher 是 Neo4j 的查询语言，风格上有点像 SQL 但专门为图设计。几个基础操作：

《Java 并发编程的艺术》个人总结

Sat, 23 Mar 2024 00:00:00 +0000

《Java 并发编程的艺术》个人总结

为什么读这本书

工作中写并发代码的机会不少——线程池、缓存、异步处理——但遇到诡异的可见性问题或死锁时，往往只能靠加 synchronized 碰运气。这本书系统地梳理了 Java 内存模型和并发工具的设计原理，读完确实对调试并发问题有了更清晰的思路。

核心知识点梳理

1. 并发编程的挑战

书中开篇说的三个核心问题：

上下文切换：线程多了，CPU 花在切换上的时间比干活还多
死锁：互相等对方的锁
资源限制：硬件瓶颈不解决，加再多线程也没用

经验上，线程数 ≈ CPU 核数 × 2（取决于 IO 密集还是计算密集） 是一个比较可靠的起点。

2. Java 内存模型（JMM）

这是全书最重要的一章。JMM 控制的是一个线程对共享变量的写入何时对另一个线程可见。核心概念：

happens-before 规则：程序顺序、volatile、锁、传递性等
volatile：保证可见性和禁止指令重排序，但不保证原子性
锁：synchronized 和 ReentrantLock 同时保证原子性和可见性

并发编程中大部分诡异 bug 的根因都是对 JMM 的理解不到位——以为一个线程写完了另一个线程就一定能读到。

3. 并发基础组件

组件	核心作用	使用场景
`volatile`	轻量级可见性保证	状态标识位
`synchronized`	互斥 + 可见性	临界区保护
`ReentrantLock`	可中断/超时/公平锁	需要灵活锁控制的场景
`AtomicInteger/Long/Reference`	CAS 无锁原子操作	计数器、状态机
`CountDownLatch`	等待多个线程完成	并行任务汇总
`CyclicBarrier`	多个线程互相等待	分阶段并行计算
`Semaphore`	流量控制	限流、资源池

4. 线程池

ThreadPoolExecutor 的核心参数关系：

主流关系型数据库的差异及性能分析

Sun, 24 Apr 2022 00:00:00 +0000

主流关系型数据库的差异及性能分析

一份中立的对比

工作中先后接触过 MySQL、PostgreSQL、Oracle，也用过 SQL Server 和 SQLite。每个数据库都有自己的设计哲学和适用场景。这篇文章整理一下个人理解，不吹不黑，尽量实事求是。

核心差异速览

MySQL：互联网的首选

核心优势：简单、运维成熟、社区庞大。

MySQL 的设计哲学是"够用就好"。它不像 PostgreSQL 那样追求 SQL 标准的完备性，而是优先保证简单场景下的性能。InnoDB 存储引擎是绝大多数场景的唯一选择——B+ 树索引、MVCC、行级锁。

需要注意的点：

对复杂查询（窗口函数、CTE）的支持较晚，直到 8.0 才比较完善
JSON 支持和全文索引够用但不强
复制架构基于 binlog，GTID 复制在管理上很便利
幻读问题：InnoDB 在可重复读隔离级别下通过 Next-Key Lock 解决，但实际上还是可能发生（快照读 vs 当前读）

适用场景：OLTP、互联网业务、读写分离架构、中小规模数据。

PostgreSQL：功能最完备的开源数据库

核心优势：SQL 标准兼容性最好、扩展性强、适合复杂查询。

PostgreSQL 是一个"学院派"数据库，它的功能完备程度在某些方面甚至超过商业数据库：

最完整的窗口函数、CTE、递归查询支持
优秀的 JSON/JSONB 支持（可以当半个文档数据库用）
丰富的索引类型：B-Tree、Hash、GiST、SP-GiST、GIN、BRIN
原生支持地理空间数据（PostGIS）
外键、触发器、函数等支持非常完整
MVCC 实现基于多版本行存储，会产生死元组，需要定期 VACUUM

需要注意的点：

连接开销比 MySQL 大，高并发短连接场景需要连接池（PgBouncer）
VACUUM 和 ANALYZE 需要关注，否则性能会逐渐下降

适用场景：复杂业务逻辑、数据分析、GIS、需要高度 SQL 标准兼容的场景。

Oracle：企业级标杆

核心优势：最成熟的优化器、最完善的高可用方案、最强的硬件利用率。

Oracle 的核心竞争力在于它的优化器和 RAC（Real Application Clusters）。Oracle 的 CBO 优化器的成熟度是其他数据库难以比拟的——同样的复杂查询，Oracle 往往能选出更优的执行计划。RAC 实现了多节点共享存储的集群架构，提供了极高的可用性。