没办法，脚本语言这块还就是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.*