虽然转换频繁，但数据不是连续的，夹杂着 utf-8，numpy 也可以胜任吗？
这两个是什么意思？
此言恐差矣。
Rust 的核心卖点是解决内存安全性问题。可是你再想想，Python 有内存安全性问题？
「Rust 的核心卖点之一是解决内存安全问题」，这是与编译型语言 C/C++ 相比。Python 作为解释型语言根本不在一个赛道上。
少量代码负责高性能计算，能有多少安全性问题
值得使用 Rust 这么重型的语言
就代码量来说 Rust 无疑是最重的，但其后端是 LLVM，很难说和 clang 相比会增加多少包袱。我不知道你说的是哪方面的「重」。就依赖管理和运行效率来看，Rust 反而是最「轻」的，而这两点上 C 和 Python 各有各的不足。
Rust 的语言模型也和 Python 不够兼容，……，内存布局和接口定义不够明确
用 #[repr(C)]，以保证布局是一致的。更不用说还有一大把包装完善的 Python FFI 库，如 pyo3 ，直接用 Rust 编写 Python 模块，连 ctypes 都省了。
但是有很多 BUG 还是没法解决啊。比如我语句的顺序写错，变量名写错，把数据库给写错了，或者提前结束了事务。等等。
你提的这几个除了第一个，Rust 还真都解决了一部分，倒是 Python 一个都没解决。
Rust 的强类型要求阻止了你变量名写错（写 Python 时我有时直到运行时才知道不小心选错了变量。由于全是动态类型，IDE 常常没有任何提示）。
至于「数据库写错了」和「提前结束了事务」，我之前了解的 sqlx 和 sea-orm 分别利用 Rust 的编译期检查和所有权机制解决了一些情况，不知道是否满足你的需求。
最近几年，我看到 C++ 的市场需求在回升。C++ 的替代器 C# 以及 Rust 在中国的热度，反而是下降的。当然，外国市场和中国可能不一样我就不太清楚了
国外的趋势确实和你说的相反。
大家可以想想这在其它语言里面怎么干？
我猜测你想说的是动态方法绑定，Java 等 JVM 语言也有的。这种用字符串能解决的工作，实在看不出 Python 的实现方案有什么美感。
依我看，交叉编译就是伪需求
嵌入式开发：？
Web WASM 程序员：？
游戏开发：？
Rust 的源码编译特别的麻烦，要下载一整套 Rust 开发套件下来
C/C++ 的源码编译不得难出一个数量级？Pypi 上没人维护的系统调用库比比皆是，一搜一大片一大片的……
Rust 的这个交叉编译，据我所知仍然要求你弄到几个平台的 Python DLL 放到你本地，又或者依赖更多的 C++ 库试试
哪个（除非极个别场景需要的）包需要「弄到几个平台的 Python DLL 放到本地」？说出来我和你一起弄他。
后面几段因为我不是 C++ 程序员，就不再妄评了。
我自己本职工作是搞 AI 的，所以过去几年接触的最多的就是 Python，估计 80% 的时间都在写 Python 代码。实不相瞒，你痛斥的这些「Rust 的痛点」，我在 Python 里无一例外遇到过，而且每次遇到都会造成糟糕的结果（挂了一晚上实验，早上起来一看，因为一个 None 或者一个变量写错崩溃了，结果全没了；开了个后端在实验室内用，没过几天就因为忘记 try except 遇到异常网络波动挂了……）。
至于说「AI 不重视性能」，这完全取决于使用的规模。对于大批量的数据集，几乎全部使用 Rust 编写的 Huggingface Transformers/Datasets 就是能比 Python 写 for 循环快几个数量级，1 分钟 vs 40 分钟，不服不行。至于遇到数值计算，那更是必须求助于 torch 和 numpy，想尽办法也要转化成线性代数算子，否则就慢慢等吧。
AI 和其他领域用 Python 最大的理由其实就是生态，大家都在迁就它的生态：你不用 Python 就没库用，你的库不用 Python 写就没人用。
我不是想说 Rust 有多好。我自己闲暇时玩嵌入式，写得最多的还是 C，偶尔会用 C++，决定「今天折磨自己」了再去花几倍的时间用 Rust 重写一遍，但否定 Rust 在其他领域的作用肯定是存在问题的。它对我个人来说最大的意义在于提供了一种看问题的新视角，例如 Enum、Trait、错误处理等让人眼前一亮的设计[1]。说得夸张一点，写其他语言时，无时无刻不在怀念 Rust 的特性和设计（尤其是错误处理，目前投入生产的语言真的没一门能打的）。
Rust 本该给 C++ 程序员（特指那些不会用现代内存管理和异常处理的）带来一些想法，加强整个行业对内存安全和程序稳定性的重视，两者应该是互补的关系。可惜的是，我看到很大一部分 C++ 程序员对 Rust 都深恶痛绝或者将其贬得一文不值[2]，好像沾到 Rust 就脏了他们的饭碗，可称为一种怪现状。
2 个赞
Pypy 是一个 Python 编译器，作为官方 Python 实现（CPython）的平替，测试性能能比官方实现高出 3 倍以上；Mypy 是一个静态类型检查器，为 Python 添加了强类型检查机制，类似于 TypeScript 之于 JavaScript。
脚注。
1 个赞
我不是开发者，所以没法很好地反驳，只是观察到平时用到的 Python 工具所涉及到的关注的开发者都对 Rust 很青睐，比如像 Beancount、Flask 这些的作者
作为一个主要看java、js，写python的人。什么时候会想起来使用python，我要干一个临时的活儿，需要解放自己的双手，十分钟写一个脚本，然后就放到旁边去自己去运行了。这种场景下，我是绝对不会想起来用java的，因为可能我的IDEA和maven还没有配置好，python都写完并且调试完了。然后当我需要找工作的时候，我就会去看java了。而关于rust，我只有在学习的时候才会想起来，因为这几条街上，招GO的都不多，更别说RUST了。
以python 为基准. 图表最后一列是其他语言对Python的性能倍数.
**测试内容：**
求0~N之间质数个数，具体求以下整数区间质数个数：
* 0~1w
* 0~4w
* 0~10w
* 0~20w
* 0~50w
* 0~100w
**强调说明**：本测试只是用来说明Python运行效率，语言其他方面的对比不属于该测试范畴！
唔，请问有源码吗，这种理论上应该把测试用的源码给出来以免从源码的循环等等各种问题造成的不公平吧……
虽然结果很符合第一直觉但是还是想问一问
求质数就是个循环. 基本上不存在算法优化.
可以看看这些，多种语言*多种算法的 benchmark
不是怕精简，而是怕故意多加一句无用循环
二编，不是恶意怀疑，只是因为之前就见过博主被人打假，原因就是在代码里恶意夹带私货负优化代码导致结果失真……所以说见了以后第一反应是问问源码……
python编译打包之后再运行？还是直接运行？这还是有点差别的
我觉得自己亲自验证一遍是最好的办法.
至于代码, 你可以问问chatgpt, 避免被人夹带私货.
有道理，只是不想在我已经很卡空间很小的可怜轻薄本上再塞几个toolchain罢了
我个人觉得这种比较没必要夹带私货.
python 性能再慢, 开发效率也比剩下的几个快.
python 的优势不是性能. 是特定范围的开发优势.
看你的用途，一般用途都不差太多。
github上有人专门用好几种常见任务测的python大概比c慢两个数量级左右。
（一众脚本语言里python也是最慢的那一批，被js的V8解释器，php和lua吊打）
比运行速度，go都不如java也罢了，还不如js了？？