感觉没戏...
天下苦cpp久矣，目测rust是最有希望成功革命的。

【 在 eGust 的大作中提到: 】
: google 家的大佬不满 c++ 委员会另起炉灶搞了个 carbon
: linus 亲自表态 rust 进内核已经不远了，按照估计12月6.1内核
: cpp 大佬赶在 c++ 23 之前放了一个还没做完的大招，看样子是想努力搞进标准
: ...................
--
FROM 114.222.220.*

跟有没有牛人关系不大，rust就没啥牛人嘛，创始人甚至就是个Mozilla这种半死不活项目组里的一个工程师。

【 在 eGust 的大作中提到: 】
: carbon 不也有一堆 c++ 委员会的牛人嘛，而且跟 cpp2 都一样直接支持编译/链接现有代码。这俩实现都还是想改 c++，至少保持兼容性，rust 属于直接换赛道了。理论上来讲，不管怎样有竞争都是好的。但这年头系统语言太多了，比如 zig、nim 之类的也都虎视眈眈，竞争有点儿碎片化了。
:
--
修改:lvsoft FROM 49.93.112.*
FROM 49.93.112.*

老兵不死只是凋零。
很多新兴语言想要占据的生态位其实也谈不上去代替谁，更多的是提供一种更好的option，然后伺机而动而已。
但rust确实是直面c/c++这个生态位的。
我觉得不好说。

【 在 GoGoRoger 的大作中提到: 】
: 没有人可以革cpp命的命，现存几十亿行的代码需要维护，cpp生态虽然烂，但也不是谁都可以取代的，看carbon做得怎么样吧。
:
--
修改:lvsoft FROM 49.93.112.*
FROM 49.93.112.*

没办法，脚本语言这块还就是bash...尽管这玩意无敌的老，无敌的慢，但它就是比python还要方便，估计轮方便程度perl能超过它，但perl门槛又远比bash高，所以...
说穿了cli本身就是一个DSL需求，py虽然是脚本语言，但自身定位还是系统语言级的定位，并不适合干这个。

我一直不太能接受整一堆container的做法...我总觉得这也是另一个层面的碎片化。尤其是看到一堆容器每个都要一个veth，ip addr给我整出一堆veth出来真就是看了就心烦...

cli/tui这块主要是现在新的语言在部署上都很给力，都具备单可执行文件一丢就部署的能力。这一点是py/ruby/perl这种老派语言完全没想过的。加上native语言体积小效率高的优势，自然就把这块吃住了。我觉得随着go/rust的生态的进一步扩张，他们可能会做现在container做的事情。

【 在 eGust 的大作中提到: 】
: 我倒觉得，其实许多本该脚本语言发力的领域，比如 cli、tui，目前 rust、go 之类的生态环境非常好。现在部署往往也都不成问题，大不了自己编译慢点儿而已。
: 现在基本除了本地工作流以外，其它的东西大多搞 container 里了，拉下来一个 image 我完全不知道也不在乎里面到底用了啥。本地 cli/tui 的话，既然有原生语言的，那我干嘛要用一个脚本语言写的。
: 的确前端方面的工具链更多感受到 native 语言在发力，esbuild、deno、bun。我现在的自己的脚本，已经慢慢改用 ts 写，也懒得编译成 js 了直接用。再加上各种 runtime 都已经支持 wasm，比如我自己的 aws 工具，就直接搞了个 jq wasm 进去，完美跨平台支持。发布只要3个文件，bin/cli.js + x.js + jq.wasm，压根不存在部署的问题。过去有类似的需求我还是主要写 ruby 的，但部署就有问题了，比如用 jq 的话就得自己先装 libjq，反正目前 ruby 还不支持 wasm。
: ...................
--
FROM 49.93.112.*

这个pycon的演讲是标题党了一点，但它的内容还是很有意思的。
它想表达的核心观点是认为整个现代os和cpu都没有存在的必要，用wasm就行了。

计算机在早期是不存在复用的。在漫长的发展过程中，随着系统越来越强，也逐步发展出了越来越多的资源隔离能力。这个演化过程是渐进的，站在现在的眼光来看未必是最好的。
比如最早是计算资源的共享，于是有了进程。为了做好进程隔离，cpu硬件上整出了保护模式，整出了ring0/3（中间还有压根就没人用的ring1/2），内存上整出了MMU，应用跑起来需要不断陷入内核态切来切去，这里都会有性能开销。后来光计算资源的隔离已经不够了，又有了虚拟机，最终演化成容器这种轻量级的全系统级隔离方案。
按他们的观点是这里这一切的开销大约有20%。

但wasm的运行环境也是一个天然的全系统级的隔离机制。而wasm对比native的性能开销也是大概20%，那这样的话，理论上cpu保护模式这种老掉牙的东西根本就不需要存在。直接裸跑wasm，然后用wasm去直接跑应用就行了。wasm的实现可以认为是一个取代了部分CPU和部分OS功能的东西，一种完全基于软件的解决方案。这个思路确实还是蛮有意思的。

【 在 eGust 的大作中提到: 】
: 反正我实在是爱不起来 bash，新来个小伙儿做了点儿东西，里面的 bash 好多语法我都没见过……有个 devops 本来是写 ruby 的，但我们的 ubuntu 环境里实在差别太大，他被迫写 py 了。我自己的 container 如果已经有 node，只要需求复杂点儿，我就写 zx.js 脚本了，各种异步执行比 ruby 方便。
: 之前说的自己的 aws cli，本来是想用来练手 rust 来着，但 aws sdk 没实现 serde。好不容易基本上能把 debug 转成 json 了，然后意识到没法 deserialize。而且官方还解释了原因，就是编译速度已经相当慢了，加了就彻底没法用了，好吧那我就不惦记了……
: container 建一堆 adapter 的确是有点儿烦，我的 mac 现在有这些：
: ...................
--
修改:lvsoft FROM 49.93.112.*
FROM 49.93.112.*