反正我实在是爱不起来 bash，新来个小伙儿做了点儿东西，里面的 bash 好多语法我都没见过……有个 devops 本来是写 ruby 的，但我们的 ubuntu 环境里实在差别太大，他被迫写 py 了。我自己的 container 如果已经有 node，只要需求复杂点儿，我就写 zx.js 脚本了，各种异步执行比 ruby 方便。

之前说的自己的 aws cli，本来是想用来练手 rust 来着，但 aws sdk 没实现 serde。好不容易基本上能把 debug 转成 json 了，然后意识到没法 deserialize。而且官方还解释了原因，就是编译速度已经相当慢了，加了就彻底没法用了，好吧那我就不惦记了……

container 建一堆 adapter 的确是有点儿烦，我的 mac 现在有这些：
$ jc -p ifconfig | jq -r '.[] | .name' | sort
ap1
awdl0
bridge0
bridge101
en0
en1
en2
en3
en4
en6
gif0
llw0
lo0
stf0
utun0
utun1
utun2
vmenet1

不过我也不会去看它们，眼不见心不烦吧……

那个 birth & death of js 的标题噱头很足，不过我并不觉得 wasm 会替代 js，至少目前看起来完全不是替代关系

【 在 lvsoft 的大作中提到: 】
: 没办法，脚本语言这块还就是bash...尽管这玩意无敌的老，无敌的慢，但它就是比python还要方便，估计轮方便程度perl能超过它，但perl门槛又远比bash高，所以...
: 说穿了cli本身就是一个DSL需求，py虽然是脚本语言，但自身定位还是系统语言级的定位，并不适合干这个。
: 我一直不太能接受整一堆container的做法...我总觉得这也是另一个层面的碎片化。尤其是看到一堆容器每个都要一个veth，ip addr给我整出一堆veth出来真就是看了就心烦...
: ...................
--
FROM 222.153.172.*

我倒是没从 cpu 层面考虑过这个问题……话说 arm 也有 ring1/2 吗？不过这个倒也是一个方向，毕竟以前似乎也有人搞过原生 jvm 指令集的 cpu。

从 wasm 目前的 microbenchmark 结果来看，基本上不会比 js 版本更快。后者我印象里大概是 2~5 倍 c/c++ 的运行时间，那个20%是1.0的理论上限？今年好像在起草2.0，不过感觉需求并不强烈，所以似乎也没有大厂投入大量资源优化 wasm jit。

我个人觉得，第一步要是能搞出来个 wasm 版的 docker，就已经能改变整个生态了。然后搞个原生基于 wasm runtime 的 os，回头再搞 cpu，似乎就是水到渠成的事了

【 在 lvsoft 的大作中提到: 】
: 这个pycon的演讲是标题党了一点，但它的内容还是很有意思的。
: 它想表达的核心观点是认为整个现代os和cpu都没有存在的必要，用wasm就行了。
: 计算机在早期是不存在复用的。在漫长的发展过程中，随着系统越来越强，也逐步发展出了越来越多的资源隔离能力。这个演化过程是渐进的，站在现在的眼光来看未必是最好的。
: ...................
--
FROM 203.184.25.*

parseInt 接受俩参数，map 提供俩参数，就这么简单。上了 eslint 这么用直接会报错

【 在 No1 的大作中提到: 】
: 昨天看着看睡着了，原来是这么个意思，我就记得个：
: ['10','10','10'].map(parseInt)
: 谁给解释一下
: ...................
--
FROM 203.184.25.*

原来如此

【 在 pangwa 的大作中提到: 】
: 不会传染， unsafe就是把风险最小化
--
FROM 203.184.25.*

刚搜了一下，有人写过概要：
https://matt-rickard.com/the-birth-death-of-javascript

【 在 DoorWay 的大作中提到: 】
: 那现在投资，应该上车什么技术栈？记得大佬您是C+python，法力无边，后来又rust。对wasm也研究了吗？
: 另外，我英语不太好，听得朦朦胧胧，他对2020-2025的预测完整翻译是什么，你能不能提炼下，以飨版友。
--
FROM 203.184.25.*