java 泛型缺点_Go 与 泛型: 优点 or 缺陷

95

2017-02-09 17:29:18 +08:00

@thekll 但其实你有没有想过，现代软件工程面对的“问题领域”其实本身很多是生安白造的概念，为了推广一些商业解决方案特意把水搞浑的。如果基于这类“领域问题”来讨论编程语言的优劣，本身就是在虚弱的理论基础上来谈的。

我举个例子(读音：再黑 golang 一把)。 golang 标榜的是解决什么问题呢，以下内容摘自( https://golang.org/doc/faq#What_is_the_purpose_of_the_project 和 https://talks.golang.org/2012/splash.article )

1. 解决类似于 C/C++ 这样的语言大规模编译时编译慢的问题

从观察来看 golang 是编译得够快的，然而 golang 能不能像 C/C++ 那样组织大规模的项目，我上一条回复说了， golang 里面的一些固有缺点本身阻碍了 golang 项目的可组织性。下文详解。并且， C/C++ 大项目慢，本身固然有 C/C++ 的头文件机制的原因，但是很多其他语言编译得很快，却不必需要像 golang 那样为了编译快对语言特性做阉割。甚至，即使以 C/C++ 的头文件、源代码分离的方式组织代码，并不一定就会导致编译慢。 只不过重新写一个 C++ 的编译器实在是太难了，没有必要。(同理，重新写一个 docker 也没有必要，这并不意味着用 golang 写 docker 就是好， 对 @CRVV 蜜汁微笑 )

2. 对软件模块的依赖的分析更容易，解决 模块正确集成的问题

哈哈， golang 自己很明显就做不到。对比同为编译到二进制代码的 mono 和 .NET CLR 是怎么解决模块版本差异的， NuGet 是怎么设计的，我喷 golang 的模块机制就是一坨屎真心不过分。

3. golang 提供 GC 和并发任务之间的通讯的基本支持。

golang 的 GC 有进步，那我就祝贺它不喷它了，反正你喷了也没有，你又不能影响或者 hack golang 的 GC 。 channel 就是所说的对并发任务间的通讯的基本支持了吧？这从来就不是什么难题，各大语言都有类似的解决方案，而且还不止满足一种模型，当然啦，有很多人驾驭不了，找到 golang 就觉得有救星了。然而这种狂热仅仅是出于无知和无能的自信。

4. By its design, Go proposes an approach for the construction of system software on multicore machines.

这个 propose 是成功的。然而很遗憾的是，也导致了一堆人只懂得这种方案。我想说，解决异步回调地狱的解决方案有很多种，通过 event queue 机制只是其中的一种；其他的方式包括：语言生成状态机( async await )； Actor 模型；

event queue 也是有缺点的，比起状态机方法，基于 event queue 异步事件的上下文依然存在事件处理内外机制的割裂问题，代码耦合性属于中等。然而 golang 在语言级别支持的 channel 很大程度阻止你们使用其他模型。