前段时间很火的 Lies we tell ourselves to keep using Golang 里面提到了：
Because they're Go experts, they know the cost of using Go upfront, and they're equipped to make the decision whether or not it's worth it. They know how Go works deep down (something Go marketing pinky-swears you never need to worry about, why do you ask?), so if they hit edge cases, they can dive into it, fix it, and wait for their fix to be upstreamed (if ever).

But chances are, this is not you. This is not your org. You are not Google either, and you cannot afford to build a whole new type system on top of Go just to make your project (Kubernetes) work at all.

之所以 devops 这块火了，刚好是因为这帮 experts 搞出了 docker/k8s。刚好因为整套生态都建立在 golang，而且放到发明 docker 的时候 deployment 的确还是个问题。

由于整套 container 的生态都是可以用 rust 重写的，而且也不是没有意义的重新实现（比如 runc 已经有 c 的实现 crun 和 rust 的实现 youki），所以长期来看这套生态是可以被其它语言替换的。甚至虽然 js 不擅长干这活儿，但突然有一天冒出来用 js 虚拟了一套 linux kernel 然后再在它上面实现 container 也不要觉得太突然，虽然更合理的情况是 js 应该走 wasm as a service 而不是 linux as a service 的路。

放到10年前，docker 还没发布的时候，市面上也没有现在这么多可以选的 better c。现如今如果喜欢 py 的语法，有 nim，喜欢 rb 的有 crystal，还有 v、zig 一堆可以选。虽然这些语言的后台都赶不上 mozilla，但基本上都是无缝使用 c 的，想用 libxxx 都不需要太多额外工作，自然 ffi 都不是问题。这么多年过去了，除了 goroutine 以外，go 有的东西 jvm 都实现了，go 和 java 真的同质性相当严重，包括语法都是上世纪的设计。跟这些新语言比起来，除了生态环境不止好上一点儿半点以外，对脚本语言用户来说，其实也没啥优势

所以呢，go 还是要感谢 google 这个亲爹，再加上生的早搞出了 container 的生态

【 在 wudashu 的大作中提到: 】
: 直接和系统/硬件打交道的时候，ffi很有用。上层业务用处倒是不大了。
: 举个例子，读硬件信息可以用udev，有ffi直接调libudev就可以了。内核版本，udev版本都不用关注，编译器会帮忙搞定，文档很齐全，升级也简单。如果没有ffi就难了，得自己想办法把需要的接口都做出来，文档维护升级都是噩梦。
: go能在运维界大放异彩，我认为和cgo关系是非常大的。这让go不仅满足了以前写脚本的运维工程师转语言的需求，还能方便的管理系统，操作硬件。
: ...................
--
FROM 203.211.108.*