@
u823tg 运行性能对不少语言本来就不重要，够用就行，现实几乎永远都是能节约开发成本更重要。
就 Python 的定位（“胶水”），性能向来就是被弱化的，但有的人被骗着骗着就觉得 Python 性能会成为瓶颈，强行要让 Python 做不擅长做的事以偷懒复用现有 Python 代码和廉价人力，结果就是迫使上游把大量资源投入到这种无底洞去了。现在回过头擦屁股，跟一开始就注意到性能瓶颈而从设计上约束，想实现相似的质量，需要花费的代价完全是两码事。像 Python 3.11 甚至爆改了 frame layout/table based exception handling 这种层面上的东西，结果体验的提升也才：“就这？”这样的费效比在工程上已经很严重了，类似的改进能持续多久属实没法乐观到哪去。当然，感知可能不明显，毕竟能有选择跳车的怕是大部分早就跑了。
至于所谓的生态不可动摇……你是不是对爆火有什么误解？能避免所谓的动摇的，只有被迫形成依赖而替换成本高企的杀手应用或者开发者（如 C++和 COBOL ），再者就是实现上有领先于其它绝大多数竞品的技术壁垒（如 Lua 和 Chez ），或者都有（如 JS ）。别的所谓生态，包括现存活跃用户的绝对数量，都没你想象中的那么不可动摇。而大多数语言都是比较尴尬的高不成低不就，(C)Python 也就是用的人特别多而尤其显著而已。（类似的例子……RoR 以前流行了好一阵子，没几年就不冷不热了。）
看你举例的备胎的例子，可以看出替换的可行性的差异感知得相当不明确。比如 C/C++可以整体被替换掉么？技术上可以，但是实际上没人能负担整体替换的成本，光考虑一点——几乎所有主要工业级的 C 、JS 和其它许多主流语言的实现都是依赖 C/C++，谁要动真格儿替换，至少还得把 FFI 之类的烂摊子收拾了，没想清楚替换哪些东西就赶鸭子上架，用不了多久就会出来各种旮旯不兼容停摆。反过来，替换“容器”“科学计算”之类的个别应用领域的东西，只要放弃少数相对来说，放弃少数设施或者人力（如果是造轮子狂魔甚至连放弃都不用），是可以短期内轻易做到避免现有基础设施的兼容性灾难的，所以仍能在合理的资源限制范围内被少数实体有效推进。这种不因为个别人意志而转移的困难程度，就是有和没有护城河的差别。而无论从哪个角度看，Python 都是属于近乎没有的。