为什么 go 和 rust 这类新兴语言发布程序大都使用静态编译？

[CrazyBoyFeng]

尤其是 go，最初的版本里完全不提供动态链接编译。
难道他们没设想过这样的情景：
某天，tls 库被爆出漏洞，go 、rust 发布了一个更新。第二天你需要升级所有依赖 tls 库的 go 、rust 应用，且需要下载的数据量十分巨大（每个应用都包含系统库 /标准库）。

其次就是静态编译对 ram 和 rom 较少的嵌入式设备太不友好。别说全用静态编译了，只要有少数几个应用是自带库编译的，那 ram 和 rom 就得爆炸了。

[waruqi]

go 原本就不是给嵌入式设备用的，即使换成动态，光这个内存占用也够呛

[holulu]

go 就是为云而生的，而云讲就是部署效率。如果每部署个应用都得搭一遍环境，安装所有依赖的动态库，还有什么效率可言？当然是直接把应用一扔就能跑是最好的。要升级？没有的事，直接开个新的虚拟机或容器，把新版本应用一放，切流量，旧的虚拟机或容器直接删掉。

嵌入式还是老老实实用 C 吧，rust 现在也可以考虑。go 就算了，自带 GC 就已经注定它不适合用于嵌入式了。

[popbones]

各有各的好处，我觉得的问题在于试图论证一个方案比另一个方案绝对的好

[whileFalse]

见识过 java 你就知道企业根本不在乎内存。

[xuanbg]

@whileFalse 内存还是在乎的，毕竟主板上插槽有限，单条容量也有限。但硬盘是真的不在乎了……几百 T 随便整，不够用上千 T 也能整出来，也没几个钱。但实际上大多数应用场景几百 G 就够用了。

[spadger]

因为存储空间不再是问题，依赖是大问题

[liuxey]

随着硬件的发展，几 M 的大小基本可以忽略
随着软件复杂度的增加，依赖就是个黑洞

[zengming00]

一个占磁盘空间只有 20M 的 java 桌面程序一运行啥也没干，内存 300M 已经没了

[love]

包含在库里的系统软件和用户自己的软件还是不同的，系统软件当然是动态链接，用户自己分发的不但数量少且追求稳妥当然是静态链接，你看 snap appimage，这种分发格式都把依赖打包成一起了，不嫌浪费内存和硬盘。

[virusdefender]

现在的 go 默认就是动态的吧

[hakono]

你别，和动态链接造成的各种版本、依赖错误，一定的性能损失相比，静态链接这点问题根本不是问题
lz 说了半天也只说了静态链接库的共通依赖升级问题。这个我觉得并不是致命的，升级你系统里的软件也不过是一个包管理命令的事情罢了，都是自动完成的，至于下载数据量大，对现在的电脑和网络来说不过是小菜一碟罢了。更何况很多 go 项目都跑云里，运行在 docker 上，系统依赖什么不过是 Dockerfile 一行命令罢了

[pmispig]

动态链接在大部分场景都不适应这个时代了，静态链接才是符合潮流的。难以想象你装个软件还要先安装一堆 A,B,C 依赖。

[dbskcnc]

dll hell 的事情也很麻烦,针对 pc,服务器而言，静态连接部署太方便了

[f6x]

以前编译 c 程序出来是一两百 K, 现在编译出来就是几 M, 还依赖十几个 so, 很可能包括第三方 so
编一个 go 程序出来, 5.6M, 无视发行版,不管什么 kernel 版本, 直接跑.

[tabris17]

动态库意味着库的版本冲突，从 ms 的 com 组件开始，就没有一个完美的解决方案

[codehz]

（没说到点子上，
动态链接 c 库肯定不是楼主想问的，那个确实都支持
自身编译成动态库才是新语言所缺少的（ go 有 plugin，但是不是 first class 的）
这里的问题明明是语言自身缺少稳定的 ABI，没法把一些语言构造很好的导出，比方说 rust 泛型的导出（ go 的 interface 导出，plugin 方式还是过于原始，再加上 go 以后也要基于 interface 做泛型了）

[linux40]

> 第二天你需要升级所有依赖 tls 库的 go 、rust 应用

没有 ABI 兼容性这一说吗？

[fatedier]

不会真有人敢随便更新生产环境的基础动态库吧？

[whoami9894]

静态编译和 RAM ROM 有啥关系

[matrix67]

从 dll hell 趟过来的！！！

从 py2 到 py3 搞一趟，就知道依赖不定死版本活该整天处理垃圾！！！

依赖一个类似 fastjson 的库活该整天升级！！

现在磁盘不值钱，网络不值钱，查问题的时间比较值钱！！！这条黑了仨！！