以前还真没关注过内存，刚搜了一下的确是差了不少。不过一般情况下，硬件成本跟人工成本是微不足道的，这也是为啥 rails、django 这些“更糟”的选择依然活的好好的。但这俩生态位的区别，其实完全不会产生到底选哪个的问题：过去用啥就还用啥完全没理由换，纯脚本语言出身的话肯定是转 go，上学时对 java 都熟的话就 java……

container 更多是一个习惯问题，我现在开发子项目基本上 docker-compose 已经是标配了，一个 db，一个 redis，目前前后端两个服务还是共用一个 container，但其实也可以分开。前段时间我特意试验了一下 win、mac 上的各种 docker，发现 rancher desktop 用起来还不错。这东西我感觉概念挺简单的，命令也设计的很友好，vscode 更是几乎原生的体验，不知道为啥推起来还是很费劲。

只要社区大到一定程度，用该语言重写其它工具只是一个时间问题。刚好昨天花了点儿时间研究 tui file manager，所以知道 lf 是重新实现 py 写的 ranger，同样 rust 重写的项目也不少。fzf 目前是老大，rust 也有类似的实现 skim，应该是接口兼容的。git 的话我知道有俩 rust 项目打算从头实现 git/libgit2，tui 也有 gitui（有段时间想写个小工具所以大概研究过）。我前段时间因为写 aws 工具研究了一下 jq，rust 这边有号称更快的重写 jaq（刚好我的刚需功能有 bug），以及类似的实现 jql。jq 作为一个好几年没更新并且还有遗留问题的项目，完全可以想象 go 肯定也有重写/重新实现的项目。

【 在 iRoNcOoL 的大作中提到: 】
: go 还是轻一些，内存用的少。实例一多，还是有区别的，一样的服务，多用机器还是少用机器
: 另外关于容易部署，在企业环境，确实到处都是 container，使得 java 之流的劣势
: 没那么明显了。但是个人环境，以及开发流程中的各种交互快捷性，go 还是更让人容易接受。
: ...................
--
FROM 203.211.108.*