- 主题:cpp大佬亲自搞了个cpp2
py在ml和学术界用的多吧，好的ml nlp的库全是py写的
【 在 eGust 的大作中提到: 】
: 说实话我个人并没有感觉到 py 的影响力有多大……平时的工作流里，只有 aws-cli 是基于 py 的。而且还只是为了 aws sso login 这一个功能，因为 aws sdk 里对 sso 语焉不详。除了它以外，最多再有个 jc 而已，还是属于一个月也用不了一回的状态……
:
--
FROM 172.56.104.*
这个有点儿远了，我一直认为 wasm 之于 js，并不是替代而是互补。一开始 node 想要调用 native 模块非常麻烦，后来有 n-api 但还是麻烦。但有了 wasm 之后，完全提供了另外一个解决问题的思路，而且只要发布一个 wasm 文件也相当方便。
另外，js 有许多 runtime，现在最火的是 node，但也有了 deno。bun 虽然很新但是已经融到了一笔钱，至少未来几年是有发展的。但竞争带来的改变却非常有趣：
1. 喊了好多年的 fetch API，node v18 终于支持了，没 deno 的话不知道要拖到啥时候
2. deno 一直不打算支持 node modules，bun 火了一把之后，马上说3个月之内支持
我目前的工作流已经尽量直接跑 ts 文件，避免编译这一步了。node 有很多历史问题，比如 commonjs vs esmodule，包管理也是乱七八糟的。deno 已经提供了一套解决方案，而前不久 bun 又提供了另一套，用的还是 jsc 不是 v8。除了 cpp 的 node，go 的 esbuild（不是 runtime 但在我 node 工作流里非常重要），rust 的 deno，zig 的 bun。说不定哪天再冒出来个基于 cpp2 + spidermonkey 的 runtime，或者 v8 用 carbon 重构，反正我不会感到意外。
另外 wasm 本身的应用还是比较广的，至少是 web service 这个方向。比如我们公司有一大堆 oracle stored procedures，产品的核心业务逻辑都是在 db 里面的。想把它们拿出来重写的话，我觉得这个场景就非常适合 wasm。前端只要浏览器不太老都可以直接用，后端如果已经自带 wasm runtime 当然最好，不带的话做成单独的 service 问题不大，前端也可以调。
【 在 gondar 的大作中提到: 】
: 你觉得啥能替代js？wasm还不成熟吧，而且搞起来也太麻烦，除了对性能有要求的，感觉wasm撼动不了js的地位，而且我知道的几家用wasm的公司，都是用的cpp
--
FROM 203.184.25.*
我知道 numpy 和 tf 之类的地位……
这个其实是 domain 方向的，好比 c++ 之于游戏开发，go 之于 containers，js 之于前端，等 rust 进 linux 内核也有相同的意义
所以不搞计算或者 ml，个人感觉基本上 py 也没有多重要
【 在 gondar 的大作中提到: 】
: py在ml和学术界用的多吧，好的ml nlp的库全是py写的
--
FROM 203.184.25.*
【 在 eGust 的大作中提到: 】
: 这个有点儿远了，我一直认为 wasm 之于 js，并不是替代而是互补。一开始 node 想要调用 native 模块非常麻烦，后来有 n-api 但还是麻烦。但有了 wasm 之后，完全提供了另外一个解决问题的思路，而且只要发布一个 wasm 文件也相当方便。
: 另外，js 有许多 runtime，现在最火的是 node，但也有了 deno。bun 虽然很新但是已经融到了一笔钱，至少未来几年是有发展的。但竞争带来的改变却非常有趣：
: 1. 喊了好多年的 fetch API，node v18 终于支持了，没 deno 的话不知道要拖到啥时候
: ...................
同意，wasm至于js是完全独立的关系，wasm可以和js等其他全部的高级语言形成互补的关系。
因此，我们也以 wasm 为目标平台和名字挖了一个 凹语言（凹读音Wa） 坑
https://github.com/wa-lang/wa
--
FROM 42.120.103.*
【 在 lvsoft 的大作中提到: 】
: 那是因为你关注的都是前端领域吧。
: 前端领域py影响力很有限，但rust也不应该是在前端领域发力的语言，现在却让我看到不少让我眼前一亮的东西。
: 比如这个
https://github.com/nitnelave/lldap: ...................
这个看上去不错，我自己家里用的nextcloud和airsonic等，本来用户管理就想用ldap统一起来，但一想到openldap那一套实在懒得弄，这个正好试试。
--
FROM 116.232.53.*
还不如加入rust，一起搞
【 在 eGust 的大作中提到: 】
:
https://github.com/hsutter/cppfront: Herb Sutter 亲自操刀：
: Cppfront is a personal experimental compiler from an experimental C++ 'syntax 2' to today's 'syntax 1,' to learn some things, prove out some concepts, and share some ideas.
--
FROM 36.112.69.*
没办法，脚本语言这块还就是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.*
wasm我也是相当的认可的~而且我被说服其实是看了这个报告。
这个虽然是pycon2014的报告，但其实跟python一丁点关系都没有...
https://www.bilibili.com/video/BV1zx411d7Gx
【 在 eGust 的大作中提到: 】
: 这个有点儿远了，我一直认为 wasm 之于 js，并不是替代而是互补。一开始 node 想要调用 native 模块非常麻烦，后来有 n-api 但还是麻烦。但有了 wasm 之后，完全提供了另外一个解决问题的思路，而且只要发布一个 wasm 文件也相当方便。
: 另外，js 有许多 runtime，现在最火的是 node，但也有了 deno。bun 虽然很新但是已经融到了一笔钱，至少未来几年是有发展的。但竞争带来的改变却非常有趣：
: 1. 喊了好多年的 fetch API，node v18 终于支持了，没 deno 的话不知道要拖到啥时候
: ...................
--
FROM 49.93.112.*
反正我实在是爱不起来 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.*
另外说起 container，docker 的作者说过，如果当时有 wasm，那他就不会做 docker 了
我觉得还是挺有道理的，只要搞出来个自带 wasm runtime 的 shell，docker 一大半的核心功能就完成了。本来 wasm 就是 sandboxed 环境，再搞搞 network、fs 等等系统资源，相应的功能搞出来的话，就是真正的跨平台，不用非得跑在 linux kernel 上了。
现在感觉大家都觉得 wasm 有用，但除了非常具体的应用场景，还是缺乏类似 docker 的产品。rust 在 wasm 方面还是有一定优势的，如果能把握住，我觉得未来还是很有前景的
【 在 lvsoft 的大作中提到: 】
: 没办法，脚本语言这块还就是bash...尽管这玩意无敌的老，无敌的慢，但它就是比python还要方便，估计轮方便程度perl能超过它，但perl门槛又远比bash高，所以...
: 说穿了cli本身就是一个DSL需求，py虽然是脚本语言，但自身定位还是系统语言级的定位，并不适合干这个。
: 我一直不太能接受整一堆container的做法...我总觉得这也是另一个层面的碎片化。尤其是看到一堆容器每个都要一个veth，ip addr给我整出一堆veth出来真就是看了就心烦...
: ...................
--
FROM 222.153.172.*