缺点：爹是 Oracle 。
好处：爹是 Oracle 。
相比之下技术特征很大程度上可以跳过……

都 2022 了……
https://bugs.openjdk.java.net/browse/JDK-4511638
Schubfach 的实现怕是到处跑了几年了，然而大概没几个知道原作者的 Java 实现和 paper 写到 v4 了吧……

这取决于用户如何理解“正常工作”。你的意思是提供部分实现原型，但用户需要的环境可能现实根本无法靠补充这个原型来实现。（虽然这里看来真不是什么问题。）
对一个有 spec 的完整的语言来说，spec 中的 conformance rules 指定了实现在语言意义上确保能“正常工作”（不符合预期就是实现的 bug ）。
典型地，如 C 这样的语言可能明确支持所谓的独立实现(freestanding implementation) ，和依赖外部环境的宿主实现(hosted implementation) ，而宿主一般意义上就是所谓的操作系统。这两类实现都实际可用。
另外，早期的语言实现直接是有没操作系统的实际实例来当作参考实现的，那自然也算能“正常工作”。
Python 官方并没有拿没有操作系统的实现来当参考实现，在 spec 的意义上也没有明确的定义，它的事实标准是 CPython 这个实现以及相关的文档，最接近的大概是 The Python Language Reference 。所以这里就有很大的用户自己主观想像的空间——除了 CPython ，和 CPython 实现多大才能算一个真正意义上的 Python 的实现？
就现实来讲，如果一个 CPython 外的实现在某个配置中能支持 CPython 支持的所有公开特性，做到 drop-in replacement ，那能算一个 Python 实现，不太会有什么疑问。否则，具体要有不兼容能容忍多少，得看用户场景。对需要依赖这些不被兼容特性的用户，所谓的“正常工作”可能就没什么意义了。
要说实现原理，唯一可能做到的就是自带模拟 CPython 实现中所有依赖操作系统的功能。有些名义上依赖操作系统的功能，像文件系统，实际上典型的独立实现照样可以实现。例如，MicroPython 提供了 os 模块的模拟（ https://docs.micropython.org/en/latest/library/os.html ）。但是这种实现的完整性是成问题的：MicroPython 就明确只提供了一个子集。
PiPyOS 可能确实比较符合原始要求；但它自带 CPython 和 OS 组件作为一部分，说这是一个 Python 实现，倒不如说是个集成 Python 运行时和自定义“驱动”及其 Python 绑定的 ChibiOS 发行版。
所以较真的话，想要“脱离操作系统的 Python 实现”，现在应该没有；以后也不大可能会有。

@adoal PyPy 可以自举。
真正的问题是一些关键功能（比如 built-in module os ）就是为了去利明确用不属于 Python 实现维护的外部操作系统去设计的，spec 都没怎么抽象而是直接暴露底层系统的语义，所以没外部操作系统支持的实现默认就是残的，跟“只能运行”直接矛盾。

@fantix 现在躺了，偶尔酱油。

@fantix 这个其实只是我的一些设想：现有的习惯（包括使用的技术的路径依赖以及行业人员的分工等等）在历史偶然的作用下已经积重难返，或许要有历史上第一次 AI 热潮这样的态度在 PL 领域上来一次文艺复兴，把现在知道的一些周知问题（特别是兼容包袱）甩掉另起炉灶，然后逐步替代现有的设计和实现，来解决一些关键的历史遗留问题；接下来自然地推广到应用，而效益上最显著的应用就是 DB 领域的 DSL 。
当然这显然过于理想化了。现实条件不成熟（有多少人对改变历史遗留问题感兴趣就是问题，然后工作量还大得离谱），实在不现实。

@fantix 基本是这样没错。不过我对现在 DB 的具体问题不了解，只能提出我认为自顶向下方面的通用 PL 能推动 query language 上最有可能的一个进展。实际上，还有 DB 业界因为解决现有普遍应用的更直接的痛点（比如嵌入其它语言实现的业务代码时开发体验和成品的效果都很不让人满意）而能改变用户习惯也现有业态的可能性，不过这个可能更困难就是了。

@fds 当年我也以为微软突然开窍了终于不再抄 UNIX （ NT ） + 套皮 DOS （ Win32 ）了，结果意料之中（？）地半途而废了……

现在商业界应该没啥好对改变这种层次的基本生态有指望了，硬说的话，唯一值得一提的就是苹果——苹果尝试首先在 iOS 上对用户隐藏传统文件系统和文件的抽象，一定程度上至少能缓解“文件”这个抽象混乱的局面（比如用户根本上不用想着纠结跨平台之间的语义差别，像为什么有的系统有所谓“设备文件”之类的玩意儿了）。问题是苹果也没提供啥实质上有效的替代，结果基本就是 API 没 abstraction ，GUI 没 metaphor ，CLI ……整个没有的局面……
题外话，苹果在软硬件结合的方面尝试对 CPU 厂商说“不”而变相架空 ISA 也大体能算是历史视角上可能整体正确的大棋，问题是它的封闭本性使之又不带其他吃 ISA 兼容性坑的小伙伴一起玩……

关于 query language 的发展，自顶向下的角度上，我现在不大看好短期（近十年尺度上）的进展。
除了 LP 方面的固有问题长期兴趣不足（所以搞 DB 的基本自己玩）外，PL 还有更大的系统性问题——大部分搞工业 PL 欠缺专业性，很多又在忙于推销产品抢占市场（包括 HR 市场），自己都未必清楚在搞啥。而研究理论自己又在玩自己的，搞工业语言的又喜欢搞 pointer analysis 这种形而下的实现问题，连现有通用 PL 的普遍设计问题都没帮上多少忙，就更别提 DSL 了。
上面工业 PL 的问题也包括现役主力通用工业语言。有些缺陷是有广泛全局影响且对用户是非常明显的，但就是长期来没法解决。
举个例子：C 和 C++ 等语言的标准库所谓的 I/O ，根本就跟真正的 Input/Output 没多大关系；事实上语言规范描述标榜 I/O 的 API 的功能的很大篇幅都溜号到“格式化”上了。然而格式化其实是数据转换，关键是这其实是一种纯计算，跟 I/O 关注的问题很大程度上根本是对立的。那么讨论真 I/O 的工作在哪呢？嗯……比如“网络库”……（不知道 C++26 能不能塞个实际能用的进去。）（ Disclaimer：当然这不是说这里的数据转换不重要；并且，要实现好这些功能需要相当专业的技能，有的还非常困难。例如，一般来说，不能指望任意一个合格的工业界程序员在不参考已有实现的情况下独自把 dtoa 这样的操作实现得正确——注意这还仅仅是实用意义上的功能正确，不限定任务时间和不要求限定实现的可移植性及性能需求；不信邪对工程水平有自信的，可以自己试试实现，体验一下会踩些什么坑。）
拿 I/O 举例是因为这对通用 PL 来说是一个普遍重要的直接应用领域：没法描述 I/O 的语言不能向反馈有意义的计算作用(computational effect) ，是没有实用性的。然而传统学术意义上 PL 研究这些年显著流行的是 PFP(purely functional programming) ，根本上就是在折腾更烂的二等设计（比如 monadic interface ），而回避如何在现有基础上更好地抽象这些功能的基础设计问题。也就最近几年 algebriac effects 才有那么点动静，然而还是非常初级的阶段（甚至可以说几乎就是换了个姿势炒 delimited control 的冷饭）。这样的进展恐怕最终并不会比第一次 AI winter 后差不多就熄火了的 LP 方面的研究高明到哪去。
举这个例子的另一个原因是，上述关于 computational effect 的研究很可能就是要做好 query language 但搞 DB 传统上就会忽视的和通用 PL 的“最大公约数”特性集的一个必要基础理论进展（主要原因是 query 本身虽然表面上 pure ，但是要做“好”query 很大程度上是 side-effectful 的，像用户自定义 effect 的局部优化策略的可表达性以及和被嵌入的环境的一致性问题上都有很大的改进空间）。
所以要靠传统意义的上 PL 研究来帮助 query language 系统性地做基础和顶层设计，短期应该是没多少指望的。于是这部分很可能仍然得搞 DB 的用户自己闭门造车。当然只是要 do better ，正常发挥下，也确实有不小可行性——至少对付 SQL 不难，因为 SQL 很多方面真的明显太辣鸡了；但是，最好别指望有多大的革命性突破，更不要指望能改变现有 DB 用户的使用习惯甚至方法论。

@charlie21 不清楚这里所谓“编程语言或者是电脑程序运行方式本身的”具体是指的什么，但这里看来是指向后兼容。
不好意思，这锅编程语言或者电脑程序都不背。
抽象未必保证封装和信息隐藏，更不直接保证可用性。是否要拆开现有的抽象设施是否包一个间接层取决于用户自己。
如果一个基础设施鼓吹的是“祖宗之法”，那决定选型的用户就该背锅。
该背锅的普遍不背锅，想甩锅的跑不掉，那就得自己反思行业问题了。

主要的背景问题是“数据库”自己就有一大坨槽点，所以相比之下 SQL 的（早就被周知的）宏观问题都可以被忽略了。
现有的 DB 专业黑话其实跟 DB 的原始主要目的——抽象地管理持久的、规模化的数据——没多大关系。
说白了，要实现好“增删改查”这种表面上最 low 东西，反而是整体 DB 的共性。但是这里相对简单的实现却被其它玩意儿——比如文件系统——抢走了，剩下搞 DB 又不愿意反攻抢回饭碗，反而在另外的领域（什么关系模型什么查询语言这些本来就跟 DB 没什么必然联系的东西）不务正业。（题外话，FS 是更不成气候抽象破碎历史包袱一团糟的领域，我是支持 DB 抢回阵地然后把 FS 这整个领域从业界开除出去到只有 history interest 的，但是现在的习惯和分工嘛……DBA 该干什么呢？）
这些做法，即便的确能实现 DB 的一部分原始目的，充其量也就是一类实现方案而已。
具体举例，RDBMS 的滥用就是一大顽疾。（ ORM 是跟 RDB 八字不合的 OO 滥用的杂交产品，算是个直接副作用的典型例子。）实际上很多场景应用的设计方案从来就不需要引入这些这些 R （进一步，domain model 里根本不该有什么 table 应该长什么样之类的问题，或者说 table 这种数据结构都算不上是个 primitive 的 building block ），所谓“关系模型最合适常规数据”也就是潜意识把 RDB 太不擅长处理（连强上 RDBMS 都没法形成业界习惯）的数据和应用场景踢出这个领域以后的胡话而已。
而所谓 query language ，说白了就是 LP(logical programming) 的一个下位应用。这个领域作为大部分用户追求“看起来怎么好用就怎么设计”的 DSL ，长期处于专业人士（ PL 专家）爹不疼娘不爱的境地，就算再有 profit 也是应用上的脏活杂活，混成这样毫不奇怪。
LP 和 declarative language 的公共问题都拎不清楚，反过来要算账自然更加糊涂。

@abeholder 跑个题，没怎么用 Docker，没遇到 WSL 问题，倒是出现过不止一次 Docker 把自己更新得起不来的状况……一次是更新后 docker.exe 就是坏的，还有一次把 docker-compose.exe 写坏了……

看标题就猜吐槽这个，还真对了。
我补个更直接的：那个分辨率，高分屏用起来就是呵呵……
然后 VirtualBox 卡翔+论坛里一坨回答的都追不上版本答非所问（当时遇到 Hyper-V 共存问题）。。。
Windows 桌面用省事还是老实 VMware 吧。

@ipwx

> CLion + CMake + C++17 + https://conan.io/

愣是凑出这么多比 C++ 设计质量更翔的组合来体现 C++ 的可用性还真是辛苦了。
（虽然确实不是没法用……忽略一些实现问题的话。）
网络连接不稳定，实现随便出点 bug，调起来是爽到飞起。

> 4 、template <typename Fn> void someWrapper(const Fn& fn)。

这是哪年的新特性。

@ericgui C++11 就允许 GC，但是没见过有厂商实现，然后最近（？）被移除了。
你说啥原因。

@likefly @byte10 能先别把冷启动响应和内存占用开除出性能么。
就算解决了这些问题，这里所谓的性能怕还是被 luajit 甚至 pypy 吊着打。
JIT 后性能飞起？ Chez 说话了？ Cling 说话了？轮得到你 JVM 跳脸？先在路线上干翻自家 Graal 再说吧。

@wangxn 性能丰富？地球上不可能找出另一个特性比它更丰富的语言？
原来我整的一坨火星语言？
随便抓过来个 spec 来自己随手往上加个新特性，你这就得自觉呵呵了。（别说加不了，先不提经手的到处都是 C# 涵盖不了特性的语言，光个 PTC 就够大部分 CLR 系语言魔改起来吃一壶了。）
而且好死不死，恰恰你 C# 比起业界大部分语言，在这里还就是说不上话的屌丝（虽然还是可以欺负下 Rust ）。
说实话，改个 C++ 成 C++/CLI 都没新造个出来那么费事。然鹅 ECMA-334 落后实际实现几年了？就微软这个 finalizer 和 destructor 傻傻分不清还是恶意卖萌（然后被 ECMA 明确打脸）的破烂文档质量还是别指望能当 spec 了。

@levelworm 如果真不确定，那么你需要实际是 owner count >= 1 的 affine type 。
这东西因为类型系统的叒鸡，C++ 表达不出来，要么就得 template<typename T> using 管它叫我特么不知道叫什么也懒得赐名的_ptr = variant<unique_ptr<T>, shared_ptr<T>>; 去近似，还不如直接 typename<typename T> using XXX = shared_ptr<T>; 得了。
前提是你真不确定，而不是滥用——像明明业务逻辑上就没 share 的没事非得 shared_ptr 。要知道 shared_ptr 没法随便 release，污染接口可能没法收场，所以设计上能不用就不用，更不用提落实到代码的实现了。
T* 说白了无非是 variant<unique_ptr<T>, observer_ptr<T>, xxxx_iterator<T>, ...> 的大杂烩嘛，这种不确定明显更欠扁，设计中几乎从来就应该拒绝出现（古董 API 中的 T* 对应的设计中，原则上也不会有这种东西，只是因为当年的语言连 shared_ptr 这种都没法明确表达又非得要用而不得不这样变通，才会让用户习惯于 T* 很正常，形成了错觉）。就算一时稀里糊涂真不确定也得 using 个 alias 出来，这样在新代码里只要看到（为了兼容历史包袱外的） T* 就可以放心视为写 bug 直接打死，而不用浪费时间多 review 了。

@ysc3839 因为烧饼 SysV base ABI 设计者的关系，使用 Itanium ABI 的主流实现中 default_delete 的 unique_ptr 不能直接寄存器传参，会有附加开销，除非指望 [[clang::trivial_abi]] 之类的魔法。（实际环境嘛，因为二进制兼容性，你懂的。）
严格来讲这不是 C++ 的错，但是这锅扣在把 C++ 变得更烂的用户的脑袋上十有八九不会冤枉好人。

@zxCoder

> 话虽如此，但我总觉得这两类之间可以不用分的这么清

然而实际上 C++ 和它们区别没那么大，所以本来就没那么清。
有区别的是 LLVM IR 之类。

> 比如能不能我也是从食材，厨具，烹饪手法都自己入手细调，但最终又不需要我自己实际动手，美团会给我做好送来

饭要一口一口吃。你确定现在的材料已经能让用户自己细调到位了？
事实上，C++ 所谓的细调明显是不合格的。否则也不会那么多用户不爽了，调一下魔改一下就好了嘛。
什么叫细？首先一个明显的表现是允许用户自己组合基本的特性，排除明显出问题的傻大黑粗。比如你作为用户看一个类型系统规则（因为语言作者抽风的屎设计）不爽，就该应当允许用可移植的方式替换掉，甚至把类型系统整个推翻掉取而代之，而不是先想破头把烂设计给干掉效果还烂（比如 C++ 式的类型擦除）。光考虑这点，所有钦定类型系统设计的语言（当然包括 C++ 在内的所有明确了类型规则的所谓静态类型系统的语言），都算不上能细调到哪去。
另一个例子，嫌弃所有钦定 GC 的语言，主要是因为有 GC 的语言原则上没法让用户干掉或者自己换一个，而不是什么性能原因（说到底对有本事改语言的用户，性能都是实现细节，因为严格意义的系统性能建模的理论几乎就是空白，语言规则根本无从提供保证）。这里算是 C++ 为数不多的还算能比较体现优势的地方。但类似的个别的差异虽然很重要，仍不足以拉开跟大多数类似缺陷语言的差距。
局部一点的设计，C++ 也是各种问题。像上面不止一个人就不爽 coroutine 这种半成品，你细一点真要面向库作者，好歹搞个 continuation 什么的吧。
……不多展开了，反正就算在这里痛打落水狗 WG21 也不会有啥感觉。

@wutiantong @junkun
> 也许说 UB 确实不准确，但是问题就在于 c++并不阻止你使用再次使用 moved 的对象，即使它有潜在的问题。就像 c++不阻止你再次使用 deleted 的指针。虽然某些次运行不会出错，但是总有出错的时候。
> 所以养成好习惯很重要，微软都有推荐用 SAFE_DELETE 置空 deleted 对象指针。也有推荐 reset 掉 std::move 后的野内存。

SAFE_DELETE 也是坏习惯，而且有会让代码变烂跳脸 no overhead 的实际风险。
好习惯是你不要惦记用过的废弃物，也不要有机会让别人误用。不管是指望编译器还是规约提醒用户显式标注，都是惦记。

要解决这里的错误风险需要完全地别名分析。内部实现就罢了，要求用户完全地人肉分析接口上出现的别名是个馊主意，根本上破坏了关注点分离——还让不让人用类型签名表达 API 了？这个意义上，C++ 的名义类型比 Rust 的结构化类型检查更符合大多数场景的设计的需要，但这也意味着完全的静态检查在理论上就不可能被依赖。

另一方面，对错误的静态归类已经产生了一些问题。Rust 的内存安全和传统方式一样不负责杜绝内存泄漏，也没在类型系统中要求这种检查，而这同样是原则上无法只知道接口的签名时完全地静态检查的（要检查循环依赖基本差不多也就是 GC 了，静态就别指望了，这里不怂不会需要有什么 Rc ）。而对最终用户来讲，不受控的内存泄漏未必比 UAF 之类的 UB 破坏小，所以实际上无法坐视不理。这个意义上，Rust 的双标给语言的用户带来的错觉会更加有不可控的风险。
背后的一个根本理由是，所有权语义是设计上应该几乎就全都应该静态明确的良定义规则，不可能只在具体代码实现中检查，需要检查也不可能只依赖编译时静态检查，更不应该有用户扔给工具就自己什么都不管的馊主意。要真这样，也甭吹 Rust 的类型检查，指望以后足够强力 GC 自动修正所有权就行了；然而 GC 当然不是强 AI，不可能彻底猜透代码之前的原始设计意图，撑死就是启发式半桶水瞎蒙最概然策略——还经常猜错。静态类型检查规则对此一样无能为力，只不过少了 GC 的自作聪明，能让用户干预，而在一般意义上更正确罢了。
这是方法论问题。

另外的一点上面提过，一个设计得能足够细调的语言，至少我是不怕缺特性的，大不了我自己加。
正因为 C++ 这方面设计不咋地，才没法让我通过写可复用的 C++ 代码（库）来方便地在上面加一个 affine type checker，实质上能把 C++ 改成看起来在这里和 Rust 差不多的东西（假设目的暂时只有这个）。
然而 Rust 就算自带了，这些功能一样没法单靠用户无中生有，而是得在语言规则里写死，因此也没法直接扩展：姑且假设 Rust 莫须有 spec，这 spec 中描述类型检查的显然会用英语混杂某种一阶语言去写，而不是 Rust 代码自举——所以要扩展就得提 RFC 之类和有本事维护语言规则和实现扯皮以后才可能实现。这跟往 C++ 里添加或修改特性，要跟 WG21 撕一样，没啥本质区别。
于是和 C++ 的差别就是，Rust 现在就多出来一些开箱即用的检查。然而这些东西上面不止一个人提过，对真正理解所有权的用户来讲，帮助并不明显；但是不提其中的错觉对其它用户的误导，多出来的编译性能开销是实打实的，谁都跑不掉。所以自然不能指望 C++ 熟练工对 Rust 脸色会好哪去。虽然类型系统的设计也许是个有趣的地方，用编译器给其他连 C++ 都不熟练的用户塞抹布节约 review 时间也可能体验比较愉悦，但真愿不愿意自己多花实现让代码更看起来 Rusty 实际自己又明白没提升啥可读性（就这些群魔乱舞的语法，降低的可能都不小）没让代码更健壮甚至都未必更清晰地现实意图，就是另一回事了。
这个意义上，两者各有千秋，却还是菜鸡互啄罢了。

@piping 哪里错了？（给全上下文了？)
比编译器不报错的问题更大的是逮住什么东西就指望实现报错。
什么叫“错”，这些用户却习惯性逃避了。
（这个意义上，顺带鄙视下设计出不允许 UB 的通用语言的方法论。）

@lesismal C++ 只要看两三百页 spec 就能上手了（除非你愿意去盯着 proposals ），篇幅而计比 Java 还省事点（这还是已经排除了框架什么的实际吃饭技术的），不知道你们看 non-normative text 读完多少书才算有懂基础这种智商税是怎么形成的。
这种语言方面的书的内容，基本全是熟练用户自己会了以后就自然知道的，也就菜鸡乐于消化别人的代谢产物了……
相比之下，Rust 因为没 spec，反而麻烦了……有时候还得盯实现。。。
提收益率的时候注意一下，你去学习一门语言，当然不只是用这个语言去写代码。
在教育语言的设计能够如何蠢以及如何比下有余比上不足来讲，C++ 无疑比绝大多数只会拎过来特性一大抄语言优秀多了。（ Rust 也算还行。）

@TypeError 引的文章有一些事实错误。因为误导比较严重所以单独说。
这篇文章和引用的其它一些链接没有分析清楚问题这个的来源，所以还有些（至少本应是）显而易见的错误。
虽然异步编程支持这方面上确实有 specific to Rust 的特别欠揍的地方，但是所谓 function 的 colour，根本上其实来自 async 。
文章认为 async/await 是一种相对于 Scheme 式的 CPS 抽象的进步，然而这是胡扯。Scheme 提供的是 first-class continuation，就是为了允许避免显式的 CPS 而能实现类似 CPS 的效果。
所谓 smear it out into a bunch of closures 在这样的支持 first-class continuation 的情形下就是一种实现细节。
想要异步代码干净，各种不同语言的设计思路都是允许用户写 direct style 的代码，然后让语言的实现自动翻译成 CPS 或者其它形式的显式异步表示形式。
这种变换，即便照顾同步 /异步的混用，逻辑上本来只要求 call site 区分所谓的 await，不需要关心是否 async 。需要区分不同的可调用实体是不是 async 的，反而把实现细节给暴露出来了。
要求用 asnyc 标注异步代码的主要原因是不愿意让运行时承担隐藏实现细节的责任，而改为强加到代码生成的机制上的偷懒，乃至于不惜牺牲接口上的一致抽象（所以有所谓的 colour 问题）。
这和滥用类型系统类似，经常就是一种过度优化（虽然影响的实现远比类型检查更麻烦）。Rust 本来就很有滥用类型系统的嫌疑，这里更容易打架毫不出乎意料。
至于 future/promise，是一种限制性的备胎而非 first-class continuation 或同等抽象能力的基础设施的替代。在语言没有能力提供健全的特性时，实现可以使用非公开的机制提供有限的 API 适用受限的场合。这可能提升特定有限场景下原语的实现质量，但也限制了通用性。

@longkas239 反了吧，没 GC 可以自己往里面实现一个当乐趣，有 GC 还能咋地，难道管 GC 调优当乐子？

流水线作业关心的是吞吐量，你管什么延迟……真 stall 住了就是财务部门失职了，约等于他们欠你的，打报告鞭笞就行了。

C 艹屎山还指望啥查找引用，记明白标识符直接开个 cmd rg 一把梭基本上都比 clangd 靠谱，更别说什么 VS 了……

@hantsy C# 是 ECMA 有标准，但是标准不是唯一的规范，很久没更新了，实际进度远远落后于作为事实标准的微软规范。
尽管微软出的规范文档质量很有问题（像 ECMA 吐槽过 MS 分不清 destructor 和 finalizer 还硬要尬聊），但新版别的地方就是没有替代，新的实现的开发也是完全由微软主导，不管是否开源都没变化。所以领导权的问题上和 Java 其实类似。

@szq8014 CPU 指令集主要是专利保护基础上的授权限制引起的问题。
Java 相当于 ISA 的部分是 JVMS 规范的东西，这个没见专利问题。
而且实际情况是基本相反，Oracle 不爽的是偏偏 Google 还不用这套，自己另起炉灶架空了这坨，“偷”走了上层生态。告的也是上面的设施（ API ）雷同。