最近在看 APUE，发现 UnixManual 和 Posix 的 API 设计与 Golang 差距好大，为什么 Golang 要这么设计？

[sjtlqy]

主要是有几点：

简化了： Socket 等 TCP 层的网络操作都被简化了； Signal 等的 IPC 交互都被简化了，还有很多等等。

添加了： 关于添加的其实没有让我难懂的，只是好奇这些 Package 添加的界线是什么呢？很多都是工具级别的，和 Rust （ Core+Std ）有很大的差别。

去掉了： IO 复用貌似被隐藏了，或者用户是调用不到了。

最后搞得我有点怀疑 Unix/Linux 的设计哲学了，我不知道这是不是在延续 Plan 9 的设计哲学？ 还是很多 System V 的 API 就是设计的太复杂了？

这样下去，是不是更加脱离了操作系统呢？不是很理解被简化得这么多了，主要还是这一点。

[neoblackcap]

上层 API 必须要将底层的 API 封装好，这个不是很正常嘛？
就算是 socket 也是有封装的，基本上你用到的都是网络层的东西，这就是封装。很正常
至于 IO 复用，当前版本的 go runtime 已经将其集成了。用 Goroutine 就可以了，调度器会自己去调度。

[darasion]

我认为：
1. 首先 golang 应该并没有打算完全替代 c ；
2. unix 设计也不是完美的，它也有各种历史遗留问题；
3. 各种计算机上古时代硬件条件限制而做出的设计并不一定符合当代现实。

[sjtlqy]

@darasion 你说的很有道理，这也许就是这些差别的根本驱动力。

但是我们如何确定现在的设计是一个优秀的在一定时间内都合理的设计呢？

在很多已经被淘汰的软件里面，应该是可以找到一些线索的。

都是好事情， 自然生长，共同维护

@neoblackcap C++没做好这方面的抽象, 也是历史所然

[neoblackcap]

@sjtlqy 我觉得 C++就压根不打算做这部分抽象工作，谁知道你想怎么样去调用底层部件。用 C++，你可以仅用轻量级线程去做网络编程，也可以用 IO 复用加系统线程去做网络编程。 C++是不假设你要干什么，它提供你自用，语言的作者本意就是不将个人的喜好强加于用户，喜欢面向对象的就去，喜欢元编程的就上。
因此我觉得这个也谈不上没做好，语言设计理念不一样。

[sjtlqy]

@neoblackcap 确实， rust 和 C++也很像， 只有一个 Core+Std 等。

毕竟是拿来干活的，就这样吧

[Mirana]

就算是写 c,也要把网络的各种具体操作抽象出来

[xxxcat]

我觉得应该是因为事件模型不同吧， unix 暴露的接口是面向 C 的，只能采用回调的形式，而 Golang 因为有 goroutine ，在编写同步形式的代码的同时还能获得异步的好处，也就没有必要再弄一套回调版的 API ，所以 Go 的 API 精简了很多。

[vinceguo]

看的是第几版？

[sjtlqy]

@vinceguo 第三版

[yegle]

Golang 不仅仅跑在 POSIX 系统里，所以不能直接把系统调用级别的细节暴露给语言？

[hucsmn]

golang 与 plan 9 的亲缘关系更近，和 *nix 的距离相对较远。例如 net.Dial 就是照着 plan 9 的 api 来做的， bufio 也是仿 的 plan 9 bio 库，还有 image/* 等等。所以， golang 和 *nix 的差异很大程度上体现的是 plan 9 与 *nix 的差异。 cat-v.org 上有很多关于 plan 9 的资料，感兴趣可以看看。

[hucsmn]

golang 标准库的功能划分有一些是仿照 plan 9 c 方言的标准库来的，去浏览一下 plan 9 的 man pages 就明白了。
还有就是， golang 是一门新语言，又是 gc 又是 interface 又是 goroutine 的，也实在没必要和 *nix api / c 那套保持一致。

[reus]

跨 os 当然要这样设计。
特定系统的系统调用，用这个 https://godoc.org/golang.org/x/sys

[sjtlqy]

@reus 多谢，以前没看到，还需要好好看文档