@lmshl 这个结论是菜鸡理解。
说学语言的目的是学语言特性，就跟学库的目的是学 API 一样。典型地没搞清目的和手段。
如果学语言的目的是要了解不同的范式，那么学会怎么使用特性是可以提供一些帮助，但是因为不熟练就没法确定是否顶用，这非常低效，是个不推荐的做法。
正常的做法是，直接把目的拔高到修改和制造不同的语言，然后才能方便在不同的语言特性中去重。语言特性不再需要是直接学习的对象，要学习的应该是语言规则怎么写的原因。理解了为什么怎么写，比理解具体是什么重要得多，也理应更加花时间消化。比较几下顺带还可以看出编写 spec 的作者的水平问题。
至于学会具体语言特性怎么用，那本来就是顺便。须知，大多数个别特性其实都不怎么顶用。归纳出什么特性组合顶用，无非是两种套路：一整个语言挨个儿学（因为一大抄，非常低效），要么就是自己理解怎么去组合。当你清楚怎么组合时，那自然就知道该怎么用了（或者说怎么批判不顶用）。
只有遇到实际需求叫你用哪个具体语言去实现什么东西的时候，再去考虑学整个语言——通常也不需要（因为绝大多数语言的设计者都有不少明确不求甚解的地方，设计出来的东西从没正常到值得你整个照搬去参考的地步）。

@tobeyoung 怎么不是呢，机器码编码的汇编语言也是语言，还不止一种。
只不过不是所谓的高级语言罢了。
JVM bytecode 的 opcode 和 IL 都是放在 JVMS 里讲的。就是 Dalvik bytecode ，也是同时给出运算格式和助记符语法的。Smali 反而不算一个很正式的语言，因为总结它的文法的正式文档都找不到。
如果 OP 说的是真的，那根本不需要有什么焦虑，因为高级语言和不高级的语言差的比多数不同高级语言之间大多了。

又不是没源码，直接本地重新编译链接会死？
还是说服务器连 gcc 这种都没有？
会死的话投诉服务器管理员，丫个生产环境都残的。

看你基础素质咯。
比如基础心率就能把你喝多少酒按着摩擦的，敢给我敬酒试试？
比如啥事不干日常就得头孢喹诺酮硝基咪唑伺候的，刚给我敬酒试试？

@ichubei 什么鬼，酒量大顶撞医嘱？
是不是上头了还能顶撞法医啊？

你确信？
JVM 的 bytecode 编码的就是一种跟 Java 截然不同的语言。

起码你遇到的还想要跟你讲礼貌。
要懂咸因，庆幸没遇到看你不爽给你一锤子开瓢的二级精神病大仙女。

@yaphets666 那你可以理解我对这些所谓大厂（或者至少是通过你理解的方式进这些厂）以及这种方式混入其中的人没什么兴趣。因为客观上讲，人数不少，入行以后对业内影响实在有限。再不乐见，我也没理由为了跟我不太搭边的下界琐事浪费太多时间。

然而 OP 说的“入行”“新人”显然并不只事关这些厂和这些人。这也是我后面“稍微离点题”而不是彻底跑题的理由。

你应该也注意到我对算法小鬼（并不表示这些人技术一定差，其中甚至可以包括某些正儿八斤的算法竞赛选手）的不爽，远甚于刷题混进大厂的。因为小鬼的层次更加高一点，和我所处的生态环境相对更相关，并且远远更容易造成破坏。

礼让行人是真的，但是那交通状况礼让不礼让都要人烦躁，至少中心城区很多年前就这样了。
离北京远，可惜离上海近。

消费 /母检法 /彩礼……都是同领域内顶流级别的雷区，一个都不去。

我暂时不具体评论 idea ，不过看起来 OP 对本领域现有进展的了解不是特别清楚：
https://github.com/yairchu/awesome-structure-editors/blob/main/README.md

@julyclyde 不是所有的实现都用 glibc ，也不是所有程序对使用过时版本的数据那么敏感（不是彻底错的基本就能用）。
不过一旦涉及到全系统的这些东西确实是有不少破事。我自己做的东西只要有可能就完全不碰这些东西，尽管这些玩意儿至少算是事实标准。

@yaphets666 是你对力量体系一无所知。
进大厂的，就算只看技术线，难道还都是量产型码农了？就算真是码农，一开始就放弃技术专长和项目经验直接比做题经验了？就算应届的，没 paper 没会议成果好拿出来水的，再次也提提 GPA 啊参赛获奖啥的啊……直接就直奔刷题了，给 reviewr 感官通常也就是这要 low 到啥层次了只能看刷题了啊。
再者所谓刷题这种形式跟进厂能有多大关系？像 PAT 之类的本来也就是给人交作业用的。（虽然当年我早刷腻 ZOJ 都没兴趣碰了，反正本来也就是建议给外专业同学玩的，本专业不做硬性要求。）就算你想认为刷的这些所谓题能说明点能力问题，好歹也得划个难度层次的吧？（然而这种层次基本是看履历……包括算法竞赛。）然后你何德何能有底气确信对大厂有意义的门槛以上的题，里面是有几个用背代码能确保解决的？

然后稍微可能离点题的题外话，这里最需要婊的其实就是“算法”题这种形式，不管背不背什么东西。
我不是说题，是说所谓的“算法”在这里挂羊头卖狗肉。
如果能顺利解题（不背），的确是有掌握具体解题方式的可能性的。但非要管这叫“算法”，那还就是有点心智问题了。因为就算没背下来，会自主写出来的这些套路，撑死就是“算法实现”，还是具体到对码农工作都难以利用的那种。
做题的过程中除了熟悉具体语言的使用，对码农有点意义的经验就是选型。不幸的是，这些题的条件跟码农的真实工作环境差太远了。决策失败的后果也和实际工作相当不同。
码农和不那么码农的工程师相比，除了默认不那么需要了解工程文档和背锅（看工作环境而异），在使用语言实现算法的工作上可能确实要求经常相差不远。但那就是 happy path 。合格的工程师还需要面对不可预期的规格错误，乃至推着 PM 不合理需求的甲方爸爸扯皮。在没有足够多工程师顶包的情况下，水平层次不同的码农都会被视为这个角色。而做题对这方面的能力毫无帮助，甚至不会增长背锅抗压能力。（虽说 ICPC 训练队友之间甩锅熟练性的可能性微存。）
真实码农的工作往往需要独自处理切换 Plan A 到 Plan B （再菜也可能遇到，区别就是 plan 和锅的大小）。而对刷题党来讲，切换只存在于错估（是否做得出来）之后重新选题的投机，在原题上继续重试的无法用合乎工程范式的标准判分，因此刷题选手会不重视这点。这导致实际上再会做题的选手也是被高估的。再无敌的码农，实际工作中也不可能什么问题都一次性解对而不需要试错，所以处理错误路径的熟练性其实相当重要，但这在做题乃至竞赛中都基本无法体现。
另一方面，训练算法题恰恰架空了什么是“算法”的内涵。
算法分析这样的最重要的一类基础在做题的实践中只是停留在表面，做题的十分之一有这个基础就不错了（我是非常怀疑现在刷题的大部分甚至都没听说过主定理）。背题或者代码会更加严重降低这个基础的要求——要看熟题的模式猜到大致出题意图，就不用管什么算法哪来的，都是套路。
实际上，就算不讨论算法题，没有独立思维的“算法”爱好者通常不可能有机会正确搞对一些基础问题——即便是最专业的算法竞赛训练也不足以提供涵盖这些背景知识。
引用我之前在氵家（ https://www.ithome.com/0/648/992.htm ）的一个回复：

算法学残的多了去了。随便抓个奥赛教练问个半算法(semialgorithm)存在的意义怕都是没底的。也难怪，一般算法描述训练时碍于理论基础不够，都用抠脚菜鸡的不严格描述（比如《算法导论》之类的伪码）入门，而九成九读者永远停留在入门阶段不懂在理论 CS 上缺了什么课要补，更不懂一般调教算法的普遍规律就是他们自以为无足轻重的语言里的——明明后者才是真正普遍的模型。这导致一堆菜鸡问题，比如要你去写个任意满足 PTC(proper tail call)的算法八成都会卡壳，因为算法用的语言太弱，要保证这种性质就得内嵌一个支持 PTC 的解释器。而训练合格到能解决这类问题的，会说自己做 calculi/semantics/computation models ，却一般不好说做 algorithm——太 low 了。

这个批评是涵盖所有自卖自夸搞“算法”的。考虑到会这样想的其实主要也就是比较不长进的码农，所以倒不必担心误伤实际上真的在从事改进和创造算法及其有效实现的工作的人。
所以你看，我其实都不太在乎背不背了。对正经码农工作，做题一直天然地比较 low ，差距还不小，所以有差嘛？

如果真有差，那么过滤口嗨的算法小学生的问题也不是没有：

算术复杂度和位复杂度有什么区别？
指针的算数操作的复杂度多少？

不是靠背，而是正经靠做题然后结合题面外的知识自行演绎理解爬上来的码农，这点应该还是能有点 13 数的（大概……）。

@misaka @interim 语感正常的话应该 tweet 直接做动词吧。

@yaphets666 比起 OP 的背景问题，你拿刷算法给“背是没有问题的”背书倒是更加让人细思极恐。

共通的问题是：
有想过谁是下达“背”的指令的甲方爸爸吗？
在自己都不清楚收益的情况下，这样的甲方会给你的“背”多少回报？
这样的甲方爸爸值得舔吗？

@julyclyde pacman -Syu 随时升级。
比较麻的是还有一堆副本……类似 mingw-w64-{ucrt-{i686,x86_64}}-{tzdata,ca-certificate}。

@u823tg 微软瞎搞也多少是传统艺能了，特别是在资源投入上……不说新语言一向资源投入拉胯，既有产品中影响最普遍最该提高性能的 cl 生成代码质量常年都占不到对面吃烂 base ABI 亏的 tier 2 支持的 GCC 的便宜，不开源经常 ICE ，还有各种兼容烂活，比如 /clr bug 导致 STL 的 pr 合不进来的。
CPython 这帮人这么“上进”往这个方向上使劲，看起来像是被人忽悠瘸了。真要性能，还不如把不跟其它更像样实现兼容的东西用 spec 当 unspecified 强行钦定了（这才是只有 CPython 的人能做得到别的备胎实现做不到的），然后架构上全面转向 RPython 之类的更靠谱的方案。当然 native intreop 前期要维持兼容肯定会多吃亏，但是兼容性包袱本就是越拖越吃亏。而要是真要那么多对性能敏感的用户，被冷落是迟早的事，加上用你 CPython 一直就是兼容性而不是指望你性能真比别人好，你继续这一苟就两方面费力不讨好。

生态问题关键就一个分水岭：有没有实体能对全局变化兜底，给整个业界买单。C/C++是不能，JS 也是基本不能，因为现有设施的依赖太离谱了，干掉一个中间环节别的看似不相干的生态都得连锁崩一大片，没谁有这本事搞事干革命突然发明出备胎，给业界兜底。光是自己不用，都至少自绝于一个主要领域，比如不想碰 JS 基本就没法玩 Web 了，不想碰 C/C++么……回家玩 51 ？——不管是找现成备胎还是自己造都不现实。要干掉这类东西，只有一点点老实挖墙脚逐步蚕食份额，长期偷梁换柱才有可能，就这样完整性还捉急。（ C++替换一部分 C 用了几十年来着； WASM 还要带一坨小弟才能干掉 JS ，属实八字没一撇了。）
Python 显然没什么本事相提并论。可以说现在技术上就不存在离开 Python 就完全停摆的业务领域。尽管要故意不用导致现有解决方案失效，业界合计损失也可能是天文数字，但如果有足够长期额外利益，立即抛弃 Python 都仍然算是人力能及，还是有找备胎平替的可能性的——即使没有备胎，短时间新造也不至于动不动发现工程上不可能。反过来，要是编译器和操作系统内核之类几乎全沾上 C/C++实现的东西现在集体完蛋不给用，你拿 jio 给你搞出个能跑的 CPython 二进制？或者用其它语言新造备胎试试，要几年？还有，这样你 Python 当胶水去打算调用个啥（这不只是 CPython 的事，此时至少 Jython 和 IronPython 的运行时实现也已经完蛋了）？
注意就算没有非得立即淘汰 Python 的理由，看 Python 不爽去 Python 化的呼声多多少少是一直存在的，没在业界全面推广，就只是没有足够共识，而不像即使万众一心想搞掉 C/C++/JS （的历史包袱）都有心无力。
Java 啊，这方面还就是大号 Python 了，区别是没那么多非专业用户，惯性也更大。跟 Python 类似，看 Java 不爽的用户也多了去了，就算没本事干掉也能划清界限。现实中没 Java 能用得好好的、甚至表现得更好的设备实在太多了。
不过这方面本来就是跑题。提到这个，起因是有人提“用的最多”，而我指出绝对用户数任意多（甚至能忽略掉“最”）都不保证不被抛弃罢了。

而且你明显完全搞反了一点，我之前根本就没评论过 CPython 官方宣传如何。这次提升的就是非本机实现性能，有人还要说“对性能依赖高的包都是 C 写的”，这明显是跟官方宣传对着干吧？

@paopjian 愿意当什么协定其实无关紧要；奇怪的是，有的人没许可证的豁免，有多大本事硬扛版权法默认条款和刑法的铁拳呢？

@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 都是属于近乎没有的。

@dragondove 用户绝对数量再多，也不表示 python 在技术上就足够擅长。很多时候某个领域突然流行某种语言或者熄火了就是偶然的非技术因素，特别是长期有很多非专业人士凑数的、菜鸡互啄的众多交叉领域。严格点说，python 长期以来都是靠用户基数和惯性大来抢占市场，没有单一的应用领域存在护城河。而用户结构的松散导致 python 在外部都很难作为事实标准。
因此想要保持生态建设的、有点危机感的语言核心开发者，是不会很乐意强调这里性能多好的——说到底满足性能需求主要就不是 python 的功劳，只是勉强达到不拖后腿，能让人用得下去，才有机会一时流行；真要极端性能的，也不是没 x 嫌弃和抛弃 python 的。相对来说，他们更希望强调作为“胶水”语言“什么都能做”，然后最好用户忘了它经常可以被低成本地替代，才有余裕争取喘息的机会，继续改进。
要等他们还清在语言设计上的技术债来甩脱对性能的质疑……下辈子吧。