学习 Rust 的工作空间, 包, Crate 和模块管理

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 语言逆天的错误处理方式

写了几天 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 异常,能程序员处理更方便,且能集中处理异常。

阅读全文 >>

用 Rust 写 AWS Lambda 的简单例子

AWS 在 2025-11-14 日发布了 AWS Lambda adds support for Rust, 即 AWS 正式支持用 Rust 写 Lambda 了, 回顾到之前 AWS 为 Rust 提供 SDK 是两年前的 2023-11-27: AWS SDK for Rust is now generally available

日常中总有几个编程语言是要去掌握的, 像基本的脚本 Bash, 网页用的 JavaScript, 大项目用的 Java, AI 时代的 Python, 再就是仿佛 Rust 也是绕不过的. 之前有学过 Rust, 到现在忘差不多了, 又看到 Tauri, AWS Lambda 对 Rust 的大力支持,有必要放 Rust 提到与 Python, Java 一样的地位来看待。尽管学习起来比 C/C++ 还陡峭,像 解引用, Either(Result, Error), Unwrap, Borrow, Move, Ownership 等概念及规则需慢慢去熟悉。

从 AWS 控制台看看 Lambda 是怎么对 Rust 提供支持的,创建函数时,Runtime 中可以选择

Amazon Linux 2023
OS-only runtime for Go, Rust, C++, custom
Amazon Linux 2
OS-only runtime for Go, Rust, C++, custom

OS 方面当然是要选择 Amazon Linux 2023 优于 Amazon Linux 2。选择 Amazon Linux 2023 或 Amazon Linux 2 时最后还有一个 custom,也就是说可以自义的定义自己的 Lambda 运行时,可选择任何语言,只要符合 AWS Lambda 调用的接口规范 Using the Lambda runtime API for custom runtimes 即可。不过完全定义吗,还挺罗嗦的,用官方直接支持的语言就容易多了。 阅读全文 >>

Terraform aws_iam_policy_attachment Policy 竞争问题

自从  Terraform  resource "aws_iam_role" 不推荐使用 "inline_policy" 和  "managed_policy_arns" 以后,就尝试了用 "aws_iam_policy_attachment" 来为 iam role 指定 AWS  内置和自定义的 IAM policy。因为在官方文档 aws_iam_role 中最先看到的就是 aws_iam_policy_attachment, 其实仔细阅读该文档的话,建议是

  1. 用 "aws_iam_role_policy" 来代替 "inline_policy"
  2. 用  "aws_iam_role_policy_attachment"  来代替 "managed_policy_arns"

然后在项目中为避免 inline_policy 和 managed_policy_arns 的警告而选择了通用的 aws_iam_policy_attachment, 同时原来也用的 "aws_iam_policy",而非 "aws_iam_role_policy。 所以才撞入到以前一直用 aws_iam_role(inline_policy, managed_policy_arns) + aws_iam_policy 就没出过问题。 阅读全文 >>

Python unittest.mock 的基本使用

平时随意用 Python 写的用了就丢的小工具当然没必要写什么单元测试,如果是一个要反复打磨的工具,项目,单元测试就必须重视起来了。因为简单思路写出来的代码将要应对各种未知情形,加之想要大肆的重构,有了足够的测试用例才能安心。

任何语言白盒的单元测试首先面对的就是 Mock,  不光是应对有副作用的操作,最好是隔离所有不在当前所见到的代码的任何调用,其实像 print 这种有副作用的代码一般是能容忍的,可能也是为何很多测试框架默认会把控制台的输出关掉。

在 Python 中,一般基本的东西自己都有,Mock 就直接用 unittest.mock,可应用于所有的单元测试框架中,如 unittest, pytest。另有一块对 uniitest.mock 的简单封装,专为 pytest 提供方便的 pytest-mock。今天先了解 unittest.mock 的使用,它的官方文档是 unittest.mock -- mock object library阅读全文 >>

Python 3.14 新特性学习(第二部分)

前一篇 Python 3.14 新特性学习(第一部分) 基本就是被 Python 3.14 标准库的多解释器霸屏,所以另起一篇继续 What's new in Python 3.14 中其他几个重要新特性。

PEP 765: finally 代码块中的控制流

编译器在检测到 finally 代码块存在 return, break, 或 continue 语句, 会触发 SyntaxWarning. 原因也很简单, 可以反问自己一句, 在 finally 放上 return, break, 或 continue 语句想干什么, 还想跳出 finally 语句块?

用 Python 3.13 和 3.14 测试下面的代码

分别用 python3.13 和 python3.14 执行

$python3.13 test.py
$python3.14 test.py
test.py:5: SyntaxWarning: 'return' in a 'finally' block
return

Python 3.14 以前不会有任何警告,但代码的执行结果是对的,只是在 return 后的代码是无效且多余的.

阅读全文 >>

Python 3.14 新特性学习(第一部分)

在 AI FIRST 的年代到底还要不要对每个所用语言新特性有所了解呢?就像有了 AI 还需要升级  Python 吗?虽然如今在 ChatGPT 中问一句话就能出来一篇比我想要写的好的多的博客,但不多思考怕会退化。

Python 3.14 于 2025 年 10 月 7 日发布,也就是前天,比起 Java 的发布节奏还是慢半拍,所以才能跟得上它的步伐。还是老方法,在官方的 What's new in Python 3.14 中吸收最原始的滋味,完后再去参考别人家的总结。

Python 官方说 Python 3.14 最大的变化包括 t-string(模板字符串),注解的延迟求值,和子解释器的支持(用以使用自由线程)。再就是标准库的变化 asyncio 的内省功能,支持 Zstandard 压缩,以及 REPL 有了语法高亮了.

总体来说这个版本比 Python 3.13 新特性更有亮点,在 Python 3.13 中自由线程是实验性的,在 Python 3.14 可通过子解释器来使用,和自由线程一样,Python 3.13 中的 JIT 需以源代码通过编译选项获得,在 Python 3.14 中 JIT 仍为实验特性,但官方发布的 Python 3.14 二进制版已包含实验性的 JIT 编译器。

REPL 支持语法着色高亮显示

为什么首先说这个特性,没有为什么。在 IDE 普遍的年代其实 Python 的 REPL 使用场景不多。在 Python 3.13 的 REPL 中首先使用了紫色的提示符,换行自动退格,块编辑,和错误信息的着色显示,代码的关键字等没有高亮显示。在  Python 3.14 中把这一块补齐了,还有更自然的 <Tab> 建议提示,如 import 时多用 <Tab> 键试试; 语法高亮的主题也可以选择。

阅读全文 >>

Java 19, 20 新特性学习

之所以把 Java 19 与 20 放一块是因为这两个版本都没有一个算得上正式的特性。都是些预览的,孵化中的,唯有一个支持 Linux 下 RISC-V 指令集与我们基本无关。所以 Java 19 和  Java 20 纯粹的过度版本,根本不该被正式项目采用,在 IntelliJ IDEA 中也是标它们为 No new language features。在我们的实践中正式项目只用 LTS 版。

还是分别从 https://openjdk.org/projects/jdk/19/https://openjdk.org/projects/jdk/20/ 抓关注点

Java 19 新特性

Java 20 新特性

从上面可以挑几个稍加了解,详细的介绍应该在学习 Java 21 时。它们是 阅读全文 >>

Python 3.13 新特性学习

相比于 Java 的每半年一个版本, 跟踪学习 Python 每年一版本要轻松一些. 虽然实际上 Java 是每两年一个 LTS 版, 但它的新特性却是逐个版本释放出来. 也终于赶在 Python 3.14 将在预计的 2025-10-07 发布之前能够学习总结一下当前的 Python 3.13 的新特性.

还是老办法, 从官方的 What's New In Python 3.13 中学习, 所以写作本文的目的就是阅读 What's New In Python 3.13 的学习笔记.

Python 3.13 最大的变化就是 REPL(Read-Evaluate-Print Loop) Python 控制台交互界面, 还有实验性的支持自由线程模型(free-threaded mode) - 即所谓的可禁用全局解释锁(Global Interpreter Lock), 和JIT(Just-In-Time) 编译器. 禁用 GLI 和使用 JIT 都可以让 Python 的执行性能得到提升.

更友好的 REPL 交互界面

Python 3.13 的 python 控制台一下子把早先的 bpythonipython 的饭碗给抢了, 虽然 bpython 和 ipython 比 Python 3.13 的 REPL 要强很多, 但毕竟控制台下只是用来随手简单测试 Python 代码, 也就更不太可能单独安装第三方的 bpython 和 ipython 了. 阅读全文 >>

学习 Java 18 的新特性

有了 AI 是不是就用不着了解语言特性本身呢?用 Vibe Coding 难道就无所不能呢?如果是的话那些找工作的也就无需刷 LeetCode 了。试想 Vibe Coding 产生了成堆的代码,即使创建了 Pull Request, 也不是给人 Review 的,也只能由 AI 来 Review, 到头来就是 AI 与 AI 自己玩,有 Bug 也只有 AI 看得懂。以后的屎山代码是一车一车的来。

除了从 JDK 官方每个版本的 What's New in JDK 18 - New Features and Enhancements, 还可以看 OpenJDK JDK 18 列出的更简明的新特性。自 JDK 10 之后,每一版的新特性由链接 https://openjdk.org/projects/jdk/<version>/ 查看,如 JDK 10 新特性链接为 https://openjdk.org/projects/jdk/10/

https://openjdk.org/projects/jdk/18/ 列出了 JDK 18 如下新特性

找几个有代表性的着重加了学习 阅读全文 >>