写了几天 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 异常，能程序员处理更方便，且能集中处理异常。 Read More- 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++, customAmazon 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 即可。不过完全定义吗，还挺罗嗦的，用官方直接支持的语言就容易多了。 Read More 
自从 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, 其实仔细阅读该文档的话，建议是- 用 "aws_iam_role_policy" 来代替 "inline_policy"
- 用 "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 就没出过问题。 Read More
平时随意用 Python 写的用了就丢的小工具当然没必要写什么单元测试，如果是一个要反复打磨的工具，项目，单元测试就必须重视起来了。因为简单思路写出来的代码将要应对各种未知情形，加之想要大肆的重构，有了足够的测试用例才能安心。
任何语言白盒的单元测试首先面对的就是 Mock, 不光是应对有副作用的操作，最好是隔离所有不在当前所见到的代码的任何调用，其实像print这种有副作用的代码一般是能容忍的，可能也是为何很多测试框架默认会把控制台的输出关掉。
在 Python 中，一般基本的东西自己都有，Mock 就直接用 unittest.mock，可应用于所有的单元测试框架中，如 unittest, pytest。另有一块对 uniitest.mock 的简单封装，专为 pytest 提供方便的 pytest-mock。今天先了解 unittest.mock 的使用，它的官方文档是 unittest.mock -- mock object library。 Read More- 前一篇 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 测试下面的代码Read More1def foo(): 2 try: 3 ... 4 finally: 5 return 6 print(123) 7 8foo() - 在 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 编译器。
Read More 
之所以把 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 21 时。它们是 Read MoreJava 19 新特性 Java 20 新特性 - 相比于 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 控制台一下子把早先的 bpython 和 ipython 的饭碗给抢了, 虽然 bpython 和 ipython 比 Python 3.13 的 REPL 要强很多, 但毕竟控制台下只是用来随手简单测试 Python 代码, 也就更不太可能单独安装第三方的 bpython 和 ipython 了. Read More - 有了 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 如下新特性- 400: UTF-8 by Default
- 408: Simple Web Server
- 413: Code Snippets in Java API Documentation
- 416: Reimplement Core Reflection with Method Handles
- 417: Vector API (Third Incubator)
- 418: Internet-Address Resolution SPI
- 419: Foreign Function & Memory API (Second Incubator)
- 420: Pattern Matching for switch (Second Preview)
- 421: Deprecate Finalization for Removal
找几个有代表性的着重加了学习 Read More