Python 之后学什么？按方向选 Go、Rust 还是继续深耕

1. 为什么 Python 不是终点，而是岔路口

聊一个我经常被问到的问题："我已经把 Python 玩得差不多了，接下来该学什么？" 每次听到这句，我都会反问一句：你说的"差不多"到底是什么程度？如果你只是能写脚本、调库、用 pandas 处理点表格、爬个网页，那坦白讲，你还没到"该选下一门语言"的时候，你只是到了"该走出舒适区"的时候。

很多人把编程语言当成一条升级路线，好像学完 Python 就一定要学 Java，然后学 Go，再然后 Rust，一路打怪升级。这个想法本身就有问题。编程语言不是阶梯，而是一个工具箱里的不同工具。Python 是那把最通用、最顺手的瑞士军刀，但你不可能用瑞士军刀去拧一颗需要套筒扳手的螺丝。"下一步学什么"这个问题的答案，不取决于你已经学了什么，而取决于你接下来想做什么。

我可以先把结论放在这里：如果你是做数据分析、机器学习、自动化脚本这类方向，Python 足够你吃十年。但如果你发现自己开始被以下这些问题困扰——脚本太慢、部署太重、并发太弱、或者想深入系统底层却总觉得隔着一层纱——那才是你真正需要换语言的时候。这篇文章我会按方向拆解，告诉大家每种情况下该选什么语言、为什么选它、以及学的时候最该抓的重点是什么。我不会给你一个"最好语言"的排行榜，因为那根本不存在，但我可以给你一张足够清晰的地图。

2. 先搞清楚一个关键问题：你是卡在哪，才想换语言？

我这些年见过太多人换语言的原因特别草率。有人是因为 GitHub 上某个热门项目是用 Go 写的，有人是因为看到 Rust 在红点上连续好几年"最受喜爱"，还有人纯粹是刷到一条"Python 已死"的标题就慌了。这些都不是换语言的正当理由。换语言的唯一正当理由是：你手头的问题，用现在的语言解决起来已经明显吃力了。

我把常见的"卡住"场景列一下，你可以自己对号入座：

• 性能瓶颈：跑一个数据处理任务要几个小时，或者你的服务在并发量上来之后 CPU 直接被打满，而你已经做了所有能做的优化——缓存加了、异步改了、算法换了——还是不够快。
• 部署与交付问题：做出来的工具是给别人用的，但 Python 那一套解释器、依赖库、虚拟环境的交付方式，让非技术用户连跑起来的门槛都过不去。
• 资源占用敏感：跑在云服务器上，同样一个功能，Python 常驻内存比你换语言之后要多几百 MB，单价一算，成本差异很可观。
• 需要深入底层：你已经触及 Python 的 C 扩展边界，或者你想做高性能网络框架、操作系统相关、嵌入式开发，Python 根本不在考虑范围内。
• 对类型系统的需求：项目越写越大，Python 的动态类型让你在重构时如履薄冰，你开始怀念编译期就能发现错误的安全感。
• 求职市场的硬门槛：你心仪的岗位明确写了要求掌握某种语言，而 Python 只是加分项。

这里我要特别说一点：如果你只是觉得"Python 太简单了，想学个难的证明自己"——那我劝你省省时间。语言的难易不是用来证明什么的。真正的高手不会因为某门语言"难"而去学它，而是因为"我需要用它解决一个用别的语言解决不了的问题"。有了这个前提，接下来聊选择才有意义。

3. 按方向选语言：数据分析 / Web 后端 / 系统底层 / 移动端，各自的最优解

既然说是岔路口，我们就按路来走。每个方向我都会给出我的首选推荐、备选方案、以及为什么这么选。

3.1 数据分析与科学计算：真正的下一步不是换语言，而是换工具链

很多人学完 Python 的分析栈之后，觉得 pandas 处理大数据太慢了，第一反应是"我是不是该学 Julia？" 这是一个非常典型的误解。Julia 确实是科学计算领域的一匹黑马，但绝大多数人的数据量远没到需要 Julia 的级别。

我先说说什么情况下才真的需要考虑 Julia：你有千万元素级别的矩阵运算、你有需要跑几小时的蒙特卡洛模拟、你做的研究需要频繁地在算法层面改动且不能忍受 C++ 的编译工程开销。在这些场景下，Julia 的 JIT 编译能让你获得接近 C 的速度，同时保持接近 Python 的书写体验。它的多重分派和微分方程生态，在做仿真和数值计算时确实是碾压级的体验。

但如果你只是觉得 pandas 慢，我可以负责任地告诉你：大概率是你的用法的锅，不是你语言的锅。比如数据量大时还在用行遍历、还在用 apply 套一个本来就慢的 Python 函数、还没有考虑用 pyarrow 做列式存储。先把 pandas 的 vectorized 操作、groupby 的底层机制、以及 Dask / Polars 这类并行化 DataFrame 库用明白，你会发现这个"性能瓶颈"根本没到换语言的份。

至于 R 语言，它和 Python 重叠度极高。除非你明确进入生物统计、计量经济学这样 R 生态占绝对优势的领域，否则我不建议从 Python 切到 R——那是平移，不是进阶。

所以这个方向的真实答案很简单：继续深耕 Python，但把 Polars、Numba、Cython、Dask 这些"性能救星"学到手。你会发现，Python 的瓶颈从来不在语言，而在你没用好它的加速通道。

3.2 Web 后端：Go 还是 Java，取决于你想去大厂还是做高并发服务

这是我在后台私信里被问得最多的问题。先给你结论：如果你刚学完 Python，想往后端深入，我首推 Go，原因有二：语言本身简单，上手曲线平滑；同时又天然适合写高并发网络服务。

Go 的并发模型是我见过最直观的。Python 的多线程受 GIL 限制，想真并行得靠多进程，而进程之间的通信又麻烦。Go 呢？一个go关键字就起一个 goroutine，你不需要考虑线程池怎么设计、上下文怎么切换——这些都被运行时处理掉了。我第一次从 Python 切到 Go 写一个并发爬虫的时候，最大的感受就是"原来并发可以这么干净"。还有一点对 Python 开发者特别友好：Go 的语法极其简洁，没有类的继承体系，没有泛型的复杂推导，几乎一周就能上手写出能跑的服务。

但如果你有明显的国内大厂求职目标，我建议你别绕开 Java。这不是说 Java 比 Go 好，而是因为市场就是这样——大厂的业务系统很多沉淀在 Java 生态里，岗位数量、社区成熟度、中间件丰富程度，Java 都有不可替代的优势。Spring 全家桶确实重，但它是能让你在企业级项目里少走弯路的框架。用 Python 入门转 Java，你需要做好心理准备：代码量会变多，仪式感会变强，但那种"一个注解搞掂一个功能"的框架体验，也是 Python 那边没有的。

这两个语言怎么选，我给一个最简单的判断标准：你更看重开发效率和并发原生的爽快感，选 Go；你更看重就业市场的确定性和企业级生态，选 Java。两条路都不堵，但方向不同。

3.3 系统底层与基础设施：Rust 是那个值得你付出学习成本的选择

如果说 Python 是"写完就能跑"的舒适地带，那 Rust 就是"反复跟编译器吵架之后，写出真正可靠代码"的硬核领域。我见过不少从 Python 转 Rust 的人，前两周都处在崩溃边缘——因为 Python 里随便造个列表传来传去毫无心理负担，但在 Rust 里，所有权和借用检查会一遍遍教你做人。

但正是这种"痛苦"，恰恰是 Rust 最大的价值。Python 让你专注业务逻辑，代价是语言层面保护不了你；Rust 让你在编译期就把内存安全、并发安全、数据竞争的隐患全部暴露出来，代价是学习曲线陡峭。如果你未来想做数据库、消息队列、操作系统、嵌入式、高性能网络中间件这类东西，Rust 几乎是目前的最优解。TikTok 用 Rust 重写推荐系统核心链路，AWS 用 Rust 做了 Firecracker 虚拟化引擎，这些都不是噱头——它们在同等性能下，用更少的人、更少的钱，换来了更高的稳定性和更低的资源开销。

但我要泼一盆冷水：从 Python 直接跳 Rust，跨度相当大，我不建议你把它当作第一门第二语言。更合理的路径是：先学 C 或 Go 把内存、指针、并发这些概念建立起来，再上 Rust 你会发现所有权模型虽然别扭，但你能理解它到底在保护什么。如果你实在想直接挑战 Rust，那就做好一个月内只写练习项目、不碰真实需求的心理准备。

3.4 移动端开发和桌面工具：你其实不一定要换"语言"

有一类 Python 开发者，他们想学第二语言的目标其实只是"能开发 App"或者"能生成一个独立运行的程序"。这个需求看着是语言问题，但其实是工具链问题。

想做 iOS App，你没得选，必须学 Swift，因为这是苹果生态的入场券。想做 Android，现在官方主推 Kotlin，但 Java 仍然有巨大的存量市场。如果你想一套代码同时覆盖两端，Flutter 的 Dart 和 React Native 的 JavaScript/TypeScript 都是选项。

至于桌面工具——我要多说一句，这其实是 Python 开发者最常踩的坑。你在 Python 里用 tkinter 或者 PyQt 写了个小工具，发给同事让他双击运行，结果对方电脑上不是缺 Python 就是缺 DLL，体验极其糟糕。你的第一反应是"我换一门语言吧"，但其实不用。PyInstaller 能打包出独立的可执行文件，配合 UPX 压缩，大多数场景下已经够用。如果批量处理脚本多、且打包体积和启动速度都让你不满意，那 C# 的 .NET 桌面生态值得看看，Windows 环境下 Visual Studio 的体验、WinForms/WPF 的拖拽开发，比你在 Python 里调 GUI 库舒服得多。

3.5 顺带一提：JavaScript/TypeScript 这门几乎绕不开的语言

还有一个方向我单独拎出来讲：前端和全栈。如果你的 Python 项目需要一个 Web 界面，而你又不想写服务端模板渲染，那你事实上已经被推进了 JavaScript/TypeScript 的领地。Vue 和 React 这两大框架，任挑一个学进去，配合 Node.js，你就能用一套语言打通前后端。

这门语言和前面说的所有方向都不一样：它不是你要不要选的问题，而是你在某些场景下根本没得选。浏览器里只有 JavaScript 是原生运行的语言，所有框架最后都要编译成它。我见过一些纯后端出身的开发者，为了做个可视化界面硬着头皮学 JavaScript，最后反而写得不亦乐乎——因为 JavaScript 的事件循环和异步模型，写起来天然带着一种"即时的反馈感"，和 Python 的脚本感有点神似。

所以如果你问"下一步学什么"时，脑子里想的其实是"我怎么把我 Python 做的东西展示给更多人看"，那答案不是换一门后端语言，而是去学 JavaScript 生态。

4. 从 Python 转到 Go 的完整路线：我实际走的每一步

既然前面把 Go 放到了首推位置，我就把我自己从 Python 切到 Go 的完整过程拆给你看，每一步做什么、为什么这么做、踩了什么坑，通通交代清楚。这比空泛地讲"Go 不错"有价值得多。

4.1 第一步：花一天把语法过一遍

Go 的核心语法量真的很小。你不需要像学 C++ 那样记几百页手册，大概一天时间就能把变量、结构体、指针、接口、函数、包管理这六件事过完。我当时是按照官方文档的 "A Tour of Go" 走了一遍，做完基础的交互练习之后，就直接上手写项目了。

需要注意的点有几个：Go 的错误处理是显式返回 error，而不是像 Python 那样抛异常，这是最大的思维转换点；Go 没有类但有方法绑定；Go 没有继承但有接口，而且接口是隐式实现——你不需要显式声明"我实现了这个接口"，只要方法签名对得上就算实现了。这些特性刚接触会觉得奇怪，但你写两周之后会发现，它们逼着你把代码写得更直白、更少魔法。

4.2 第二步：拿一个 Python 小项目重写练手

学习第二语言最有效的方式，不是看教程，而是找一个你之前用 Python 写过的、小但完整的项目，用新语言重写一遍。我当时选的是一个给公司内部用的日志分析小工具，大概三百行 Python 代码，功能是读取多个日志文件、按正则提取关键信息、做统计并生成 CSV 报告。

用 Go 重写这个项目，大概花了我三天时间。这三天里我学到的东西，比看十篇入门教程都多：我怎么处理文件遍历、怎么用 goroutine 并行解析多个文件、怎么在 Go 里优雅地处理正则表达式（Go 的正则底层是 RE2，不支持反向引用，这在 Python 里是有的）、怎么用标准库里的 encoding/csv 生成报告。写完后你会发现，你的"Go 水平"不是"学过 Go"，而是"真的写过 Go"。这就是项目驱动学习的力量。

4.3 第三步：彻底搞懂 goroutine 和 channel 的模型

这是 Go 的核心，也是最容易让 Python 开发者困惑的地方。我可以用一句话概括 Go 的并发哲学："不要通过共享内存来通信，而要通过通信来共享内存。"这句话听着绕，翻译成大白话就是：Python 里你若想让两个线程协作，通常要搞一个共享的队列，然后加锁保护；Go 里你让两个 goroutine 各干各的，需要用数据了，通过 channel 传过去，channel 本身就是并发安全的。

我建议你用三种方式练手：先写一个简单的并发爬虫（比如并发抓取一百个页面）；然后写一个 worker pool 模式的小工具（创建固定数量的 worker，从一个 job channel 里取任务）；最后写一个带超时控制的并发任务（用 context 包协调多个 goroutine 的取消）。这三个练习做完，你对 Go 并发的理解基本就到位了，不会再把它当成"写起来像线程的东西"。

4.4 第四步：学习标准库和常用框架

Go 的标准库之强大是我用 Python 转过来后感受最深的。Python 做 HTTP 服务，通常要装 Flask 或 FastAPI；Go 的net/http标准库自带 HTTP 客户端和服务端，性能还很能打。文件处理、JSON 序列化、模板渲染、测试框架——这些在 Python 里要分开装的依赖，Go 标配套餐全有了。

真实项目里建议直接从数据库接入开始做，选一个熟悉的 SQLite 或 MySQL 操作，配合database/sql标准库和sqlx第三方库，把增删改查跑通。然后做 REST API 服务，用gorilla/mux或gin框架，把路由、中间件、错误处理、JWT 鉴权串起来，一个完整的后端服务脉络就建立起来了。你会发现："原来用 Go 写后端，不是比 Python 更有表达力，而是更省心——部署时只需要一个二进制文件，没有依赖地狱，扔到服务器上就能跑。"

4.5 第五步：用地道的 Go 风格重新认识测试和部署

这个步骤很多人会忽略，但它才是让一个"会写 Go 的人"变成"懂 Go 的人"的关键。Go 自带测试框架，你用go test生成测试文件、写表驱动测试、跑覆盖率分析，整个体验比 Python 里配置 pytest 和各种覆盖插件要顺滑很多。部署方面，go build直接产出静态链接的二进制文件，你可以直接在本地编译好扔到 Linux 服务器上跑，不需要在服务器上装任何运行时。这一步对 Python 出身的人来说特别震撼——我第一次这么做的时候，盯着屏幕上那个独立运行的二进制文件看了好几秒，脑子里全是 Python 项目部署时装环境、配虚拟环境、处理依赖冲突的记忆。

5. Rust 不是难，它只是换了一种思考方式：Python 开发者最容易踩的坑

我前面说过 Rust 是系统底层的方向，但如果你就是铁了心想学它，我也拦不住你——那就拦不住你，我就把手上的经验全倒给你。从 Python 转 Rust，最大的坑真的不是语法，而是"你的脑子还停留在 Python 的模式里"，尤其是下面这四件事。

5.1 所有权模型：Python 垃圾回收给了你"懒惰的权利"

在 Python 里，你从来不关心一个对象什么时候被释放，因为有引用计数和垃圾回收兜底。到了 Rust，一切都要你自己负责：每个值只有一个所有者，所有权可以借用但需要标注生命周期。我第一次写 Rust 代码时，内心全是这样的念头："我就想把这个字符串传进函数里，然后原变量我还要继续用，怎么编译就过不去？" ——这就是所有权模型给 Python 开发者上的第一课。

我给的实用建议是：先别急着背规则，你只需要记住三个词——所有权、借用、生命周期，然后用代码反复去撞编译器。Rust 的编译器是我见过最友好的，每次报错都会告诉你为什么错了、建议怎么改，有时候甚至直接给出可复制的修正代码。你想让编译器闭嘴的方法只有一个：按它的逻辑把代码写对。这个过程有点像跟一个极其严格但逻辑清晰的导师对话，虽然痛苦，但确实长进快。

5.2 没有 class，只有 struct 和 trait：接口思维的大转弯

Python 开发者习惯用类和继承来组织代码，到了 Rust，你得把脑海里"继承"两个字删掉。Rust 用 struct 存数据，用 trait 定义行为，数据类型和数据行为是正交分离的。举个例子：你在 Python 里可能写一个class Dog(Animal)，再重写make_sound方法；Rust 里你是一个struct Dog，然后为Dog实现impl Speak for Dog。前者是"狗是一种动物，它通过继承拥有发声能力"，后者是"狗这个数据和发声这个行为之间存在一种实现关系"。

这种设计的好处是：你从"类型继承"的僵化结构里解放出来，多个 trait 可以随意组合，灵活度和复用性都高得多。坏处是：你的设计模式要重新学。很多 Python 里靠多重继承和装饰器绕来绕去才能搞定的扩展需求，Rust 里一个 trait 加上泛型约束就解决了。

5.3 错误处理：不是 try/except 一抛了之

Python 的异常处理是流程式的一路往上抛，你可以在任意层级捕获。Rust 的错误处理是返回值式的：一个函数要么返回Ok(value)，要么返回Err(error)，你必须显式处理每一种情况。标志性的?运算符，本质上就是一个"失败就向上返回错误，成功就取出值"的语法糖。

对 Python 开发者来说，这是三观的重塑——因为 Python 允许你"偷懒"：内层函数抛个异常，外层函数不接，程序就直接蹦给你看。Rust 逼着你每一步都清清楚楚地处理"失败"这件事。初学的时候会觉得烦，但真写多了你会发现，"错误分支都被你显式处理过了" 的代码，跑起来比 "满屏 try/except 但实际大概率没抓住正确异常" 的代码要可靠得多。

5.4 把朋友从 Python 带到 Rust 的"苹果游戏"练习法

如果前面这些概念还是太抽象，我给你一个特别具体的入门练习，很多从 Python 转 Rust 的朋友反馈这个练习帮了大忙——做一个命令行版本的猜数字游戏。这个游戏虽然小，但涵盖了 Rust 的所有基础概念：你需要读取用户输入（io 操作）、需要做字符串转数字（错误处理）、需要做一个循环（控制流）、需要比较数字大小（借用和引用），最后还要把所有逻辑封装进一个函数并写一个测试。我强烈建议每一位想入门 Rust 的 Python 开发者先过这一关，而不是直接从"写一个 Web 服务"开始——后者一方面容易打击信心，另一方面你的 Rust 语法还没站稳，会写出语法正确但风格丑陋的"Python 式 Rust"。

6. 不换语言，也能大幅提升效率：Python 本身的性能进阶路径

聊到这个位置，我必须说一句很多博主不爱说的话：很多人问"下一步学什么语言"，本质上是在逃避"下一步该怎么提升"这个问题。

如果你对现有语言没有硬伤不满，只是觉得写出来的东西不够快、不够专业，那答案可能不是换语言，而是把 Python 用得更深。我自己在实际项目中最常用的几条性能进阶路径，每条都实打实地让我把一个原本跑到两小时的任务缩到了十分钟以内：

• 向量化操作替代逐行循环：pandas 里对每一行做apply，本质上还是在用 Python 循环；改用 NumPy 的向量化函数或 pandas 的transform批量操作，同样的逻辑跑起来通常会快上十到五十倍。现实中我见过太多人拿着 DataFrame 一行行刷循环，完全没用到 pandas 背后的 C 实现。
• Numba 加速数值计算：Numba 是一个 JIT 编译器，你在 Python 函数上加一个@njit装饰器，它就能把函数编译成高效的机器码。对纯数值计算（循环、矩阵运算、蒙特卡洛模拟）效果极佳，不需要改算法逻辑，单纯一个装饰器就能收获几十倍加速。我做量化回测时，很多时候就把核心计算函数用@njit包起来，整体回测速度直接起飞。
• Polars 替代 pandas 处理大数据：Polars 是基于 Rust 写的 DataFrame 库，它跟 pandas 的 API 神似，但底层是列式存储和并行计算。如果你遇到 500MB 以上的数据，直接用 Polars 读，你会发现"pandas 慢得让人想换语言"的问题瞬间消失了。
• Cython / C 扩展：这是最硬核的一条路，适合那些已经完全确认 Python 动态类型开销是瓶颈、而且上述优化方案都试遍了的人。Cython 能让你在 Python 和 C 之间衔接，核心热点函数用 C 写，外层用 Python 调度。这实际上是"用 C 做优化"的一部分，你已经算半个"开发者"了，距离真正去学 C 也就一步之遥。
• asyncio 改善 I/O 密集型代码：如果你的瓶颈是网络请求、数据库查询这类 I/O 等待，那跟语言并行关系不大，用 asyncio 把同步阻塞改成异步等待，吞吐量能提升一个数量级。

这一板块的存在是想告诉你：技术升级不等于换语言，用深用好现有工具，有时候才是对你现有项目投入产出比最高的事。只有当你把这些路径都走完了、确认Python的某些能力天花板确实存在，换语言才算是一个"认真思考后的选择"，而不是"逃避学习深度的借口"。

7. 我踩过的三个真实坑：供你少走弯路的实战提示

前面写了很多方法，但干货如果不到"踩坑实录"的级别，总觉得不够尽兴。我从 Python 转向多语言的实践里，挑了三个最有代表性的坑来交代。

7.1 用 Python 的思维方式写 Go：到处都是闭包和 goroutine 泄漏

我第一次学 Go 时犯的最大错误，就是把 Python 里那种"随手起线程、随手不用管"的习惯带了过来。Python 的线程确实粒度粗，你一般不会去细分清晰的生命周期。Go 里 goroutine 非常廉价，你会忍不住到处乱开，结果是不是泄漏就是死锁。而且在 Python 里闭包是随手写随手用，Go 的闭包捕获变量却是"你可能以为捕获了副本，实际捕获的是引用"，循环变量那个经典问题我踩了整整一次，排查半天才发现所有 goroutine 读到的是同一个i的最终值。这个经历教会我一件事：换语言先阅读它的官方格言和设计哲学，比先写代码重要。Go 的哲学就是"简单、直接、明确"——任何绕过这个哲学的写法，大概率都是在用自己的旧习惯坑自己。

7.2 因为"觉得 Rust 帅"就学 Rust，学到第四天就放弃

这不是我瞎编的，是很多人在后台私信里跟我分享的共同经历。大家一开始都很上头，觉得 Rust 是"最受喜爱语言"，学了 Rust 就高人一等。结果学到所有权和借用检查那两天，语法还凑合，一到写实际项目就处处碰壁，于是崩溃退出。我当时的建议是：千万别直接拿 Rust 开发正经项目，先用 Rust 重写一个你写过的小工具，允许它丑、允许它慢、允许它不像真正的 Rust 代码——你的目标只有一个：让编译器闭嘴。编译通过了，再回来重构、再写复杂一点的逻辑。不要和"帅"较劲，要和"编译通过"较劲。这一条建议帮过不少人，今天也放在这里。

7.3 学了一大堆语言，但没有一个是"能拿得出手的"

最后一个坑最具普遍性。很多人看我文章看得热血上头，这个月学 Go、下个月学 Rust、再下个月想学 Elixir……结果一年过去，哪个都只会写 hello world，哪个都不能实际干活。我本人虽然没有这么不上心，但我确实见过太多"语言收藏家"。收藏语言的快感来自"我觉得我会了"，但真实能力来自"我拿它做完了哪件事"。我给自己定的规则是：一门新语言，只允许学一半的时间和精力在语法层面，另一半必须砸到一个真实任务里。任务不要求大，比如"写一个命令行工具管理我的待办事项""写一个脚本来分析我的阅读记录"，完成即算入门，否则一律不算数。这个规则我用了很多年，每次都能让新语言真正变成我的工具，而不是我的谈资。

8. 最后一句话：语言是工具，项目是目的

写到这里，说点掏心窝子的话。我从一个只会 Python 写脚本的人，走到今天能按项目需求在 Python、Go、Rust、JavaScript 之间切换，最深的体会是：学习编程语言的最佳时机，永远是当你手上有一个需要它的真实项目时。没有需求驱动的学习，很难持久，也容易沦为自我感动。反之，只要你背后有明确的应用场景，语言只是你解决问题时顺手拿起的工具，换个工具不过是从一个工具箱换到另一个工具箱的事。

我自己到现在仍然用 Python 做数据分析和快速原型，只有在写高并发服务、做系统级组件、或者需要极低资源占用的时候，才会切换到 Go 或 Rust。语言之间不是替代关系，是分工关系。所以别再焦虑"Python 是不是过时了"——真正过时的，不是某一种语言，而是"只会一种工具却说自己会编程"的错觉。

如果你看完这篇依然不确定该怎么选，就回到最初的那个问题：你最近一次被现有语言卡住，是在哪个场景？卡住你的那个场景，就已经帮你把下一步的方向写好了。