Golang Go语言与泛型：优点 or 缺陷
之前看到 Go 中国 的文章: 为什么说 2017 年你必须要学习 Go 了
其中把 Go 语言没有泛型作为其优点之一.
昨天晚上看到新发的文章: Russ Cox 的 2017 年 Go 开发计划
注: Russ Cox 目前是 Go Team 的 leader
其中对于泛型有这么一两句话:
我不相信 Go 团队曾经说过“ Go 不需要泛型”
但我们确实明白，对于 Go 来说缺乏参数多态性是一个显著的障碍。
这样看来, 在 Go 开发团队眼中, Go 没有泛型并不是一个优点啊.
Golang Go语言与泛型：优点 or 缺陷
更多关于Golang Go语言与泛型：优点 or 缺陷的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
我们对泛型的需求和文章中提到的差不多，即借助泛型来实现一些特殊需要的通用数据结构或算法。没有泛型的话，代码多了不说，更主要是容易引发转型的 bug 。
其实这个我也是不太抱希望的。现在已经有一些可用的包管理器了，但最大的问题是有好多开源包并没有按照语义化版本来发布。这个要规范起来也需要很长的时间。
golang 的能力相比 C# 加上 AOT 之后，优势就所剩无几……
C# 在跨平台开发上还有 Xamarin 之类的撑一下场面
golang 除了写 业务 server 之外，没有想到任何别的场合是能用的。
这话怎么这么奇怪
C, C++, C#, Java, JavaScript, Python, Ruby, Haskell 都缺失了 Common Lisp 的宏
Common Lisp 缺失了 Haskell 的 Type Inference
请问 2017 年应该用什么语言？
要这么说的话……那应该 C/C++是世界上最好的语言？毕竟 Linux ， Windows 都是用它们写的。
golang 有什么特点可以说明 docker 这样的软件用它来写是最好的呢？
我觉得只有“适逢其时” 这一点了。
话说， Mono 或者 .NET runtime 本身就是一个 可以自行隔离多个组件的 VM 呢，
C# 的动态加载 API 也能支持这一点，这难道不比 golang 屌么
我仅仅是回复了 “ golang 除了写 业务 server 之外，没有想到任何别的场合是能用的” ，表达一下 Go 还有其它的场合“能用” 而已
我没说 Go 在这两个场合好用，我也没说它是一个好语言，我也没说它比任何一个语言好
你这回复得莫名其妙
最近用下来， golang 是一门不错的语言。一定要让我在 golang 和 c#中放弃一门语言(注意，不是选择)的话，我肯定选择 C#。
golang 能做什么？什么只能用 golang 来做？
这个世界有这么多门语言，有什么是只能用一门语言来做的吗？
没有一个语言是最好的。
golang 现在编译快，概念少，有 GC ，明显 直接 的竞争对手是部分脚本语言的领域。
静态理性，部署容易，性能略高。
我用 golang 是用来代替了很多我本来用 Python 甚至 Nodejs 做的事情而已。
至于为什么放弃 C#,还有比 c#更 尴尬 的语言吗？ c#似乎在哪个领域都做不到老大？
说句不好听的。只能用一门语言来完成工作处理问题的，还能叫程序员？
既然要学多门语言，易学部署容易的优势还不够大吗？
Golang blog 在 2010 年就说过了,尤其最后一句 - "我们写了越多的 Go ，就越发现不需要这个 feature"
Do you have plans to implement generics? Many proposals for generics-like features have been mooted both publicly and internally, but as yet we haven’t found a proposal that is consistent with the rest of the language. We think that one of Go’s key strengths is its simplicity, so we are wary of introducing new features that might make the language more difficult to understand. Additionally, the more Go code we write (and thus the better we learn how to write Go code ourselves), the less we feel the need for such a language feature.
我觉得很多人在讨论语言的时候，经常会陷入一个思维误区。
不存在“世界上最好的语言” -> 语言之间没有优劣之分。 请问这个推导你认为成立吗？
我认为不成立。
C# 部署难吗，有 .net 就 .net , 有 mono 就 mono ， 两个都没有，我还能 AOT 成本地二进制。部署难吗？
C# 尴尬吗？ 如果做不到老大就尴尬，那么 golang 应该跟着一起尴尬吧？ golang 在哪个领域做到老大了？ 高性能服务器依然是 C++ 为主流，复杂的大规模服务 Java 是主流，请问你 golang 算老几？
说句不好听的，能用一门语言解决问题，为什么要用多门语言？ C# 能搞定 PC 端，移动端，服务端，浏览器端，为什么要多搞几个人？
当然啦，我也不是介意多学 几门语言，然而学了几门语言之后还想一头扎进 golang 的话，那真是没悟性。
我认为语言之间当然没有优劣之分，只有适合不适合。
部署和 golang 比，非常难。
能用多门语言。为什么要用一门？好好写过程序就知道了，一门语言搞定所有，大概你一个 shell 能搞定的事情也准备起个 c#?问得出这个问题的绝对属于思路精奇啊。
c#作为一个 java 的 copy 者和竞争者，现在混成这样还不尴尬？
多年没接触 c# 了，现在 mono 生产环境工作正常吗？图形界面能够在 linux 下工作了吗？如果.net linux 支持做好就非常棒了。
.NET 的问题感觉出在微软主导，我记得当时 mono 还被告了，要求贡献 mono 代码的人不能看过 .NET 的反编译。这么做使人对 .NET 跨平台兼容没信心，不知道什么时候 mono 就被微软搞死了。
没有泛型支持一直不是优点， go 官方打算加泛型，结果因为历史遗留问题很难加…
另外错误部分也比较坑，像是标准库网络错误，想要确定具体的错误类型居然要用字符串查找…
个人感觉 go 适合服务端编程，写起来很省心，没有回调地狱模式问题。另外写一些小的服务器工具也是合适的，但是图形界面部分不好用，或者说是我没接触 go 图形界面编程。
然而现在 Xamarin(mono)都被微软收购了，开发速度、代码质量在过去一年内也有显著的提升（虽说貌似有大把大把地抄微软开源的 .NET Core 和 .NET reference source ），你还觉得它会死吗？
C#和 mono/.net 是两个问题。
图形界面不是 C#原生的内容，用 gtk#/qt 之类的跨平台是没什么问题的。 mono 刚出来的时候做跨平台的 ui 程序就很容易没什么问题。
说的出这些话的还好意思说什么降维攻击？
看清楚我原话了吗？
Copy 和竞争者。
c#和 JAVA 的关系，和语言中的那些细节有什么关系？
谁关心语言的细节了？正常人都是关心的应用场景，谢谢。
无耻之尤。 我说了 C# 里面有 而 Java 没有的东西来证明非 copy ，你却跟我说不关心细节～ 那你 golang 不也是 copy C 语言吗，谁关心语言细节了？
关心应用场景？好啊，那你说说 golang 怎么写 各种平台上的 GUI 应用啊？
Xamarin 有印象，记得看 keepass android 源码时发现的，当时想编译下 keepass 发现连免费试用都没有就没再看。现在看好像有免费社区版了。 当时 keepass 的几个实现大部分都是 .NET 的实现，唯一一个纯 java 的实现比.NET 的实现慢了很多…
问题是一般 vs.net 就用 windows 的实现，后期再改好麻烦…
现在 .NET 小图形界面做 windows + linux + macos 跨平台用哪个方案方便？
所谓的图形界面就是封装一个控制台程序，只用有启动、停止、重新启动按钮外加重定向控制台输出到图形界面文本框。
是不是 mono+aot 后就不用部署 .net 运行时了？
可怜我只写过 Mono devaloper 的 gui 到 win 上用，没怎么写过 win 下的 GUI 程序。 windows 下用 c# 主要还是网络相关的。
我司线上服务器用 mono 已经很久了。
如果你说 C# GUI 开发就是指 WPF 之类的话，这当然是没有的。
但是 xamarin studio 本身就是一个很好的 C# 跨平台 GUI 开发的例子。
一方面说语言没有优劣， 然而 golang 又自称以 better C 为目标，你们 gopher 真心精神分裂啊。
既然 golang 以 better C 为目标，那现在混成这样也挺尴尬的，嵌入式也用不了，高性能也比不上，说广泛使用吧也不如 Java 。除了有一个三心二意的爹之外一无是处啊。
golang 有啥有资格看不起 C# 么？ 做 3D 有 Unity ，做跨平台 GUI GTK#， Bridge.Net 把 C# 编译成原生 Javascript ，这样的话连 HTML 都不用写，不想装运行时可以 AOT 。 你 golang 连个 hot fix 都解决不了，真不知道有啥好吹牛的。
"另外错误部分也比较坑，像是标准库网络错误，想要确定具体的错误类型居然要用字符串查找… "
1. 字符串查找是错误的方法，因为返回的字符串依赖于操作系统和操作系统的语言设置
2. 同样的错误，不同的操作系统会返回不同的结果，有的错误只存在于部分操作系统上，如果要做一个完全和操作系统无关的 net 库，这个问题就很难解决.
比如 Java 的 ‘ new ServerSocket()’ 会抛 java.net.BindException ，这个异常的原因可能是 EADDRINUSE 或者 EACCES ，也区分不出来
3. 2 里的例子，用 Go 可以区分，只是比较麻烦，并且依赖于特定的 Go 版本。能在 1.7 上用的代码是<br> _, err := net.Listen("tcp", "localhost:123")<br> if opErr, ok := err.(*net.OpError); ok {<br> if syscallErr, ok := opErr.Err.(*os.SyscallError); ok {<br> if errNo, ok := syscallErr.Err.(syscall.Errno); ok {<br> switch errNo {<br> case unix.EADDRINUSE:<br> println("EADDRINUSE")<br> case unix.EACCES:<br> println("EACCES")<br> }<br> }<br> }<br> }<br>
结论是，这不是 Go 的问题
C# 很好，但我发现一些公司因为招不到足够多靠谱的 C# 程序员而正在选择转 Go ，这一点值得注意。大部分使用 Go 的公司，程序员都是从 c++ 之类的转过去的，相对来说容易很多。
better C 本来就是试图在 C 用的场景上做的更好啊。
至于 C 和 golang 哪个应用的更广泛，在大部分场景中更有优势，自然是 C 啊。
只有你在这里看得起看不起啊，我之前就说过我也写过 c#，难道我还看不起我自己么？
至于吹不吹的。
go 吹的数量能和 php 吹， c#吹， java 吹比么……
我记得当时也尝试过这种，但是跟进去发现中间错误类型是 net 库私有类型，再拷贝出来强制转换麻烦，而且标准库变更结构的话程序会挂。
查询网上没什么好的解决办法， go 本身就不建议程序区分错误类型，用的又不多，就直接字符串查找了。
这是另外一个话题了。老板都想招到即插即用到岗马上能干活的程序员，但技术变化那么快，抱有这种把人当机器的想法当然是事倍功半的。 能好好写 golang 避免不必要的 copy ，避免过迟 defer 的你以为很多么？
golang 吹 v2 上特别多。其实吹也不是什么问题， php 吹通常承认自己懂得不多， Java 吹也比较老实不吹语言特性。 可 golang 吹里面，写过 C/C++ Delphi Pascal 之类原生语言的特别少， 连 linker error 都没遇见过的，大多数是从 python nodejs 过来的，却要做 better C ，那就比较令人无语了。
你第一个回复是 16 楼
能否告诉我，前 15 楼哪个是 golang 吹？
这个楼里 你 过的为
CRVV,我
怎么看都只有我拿 java 黑了 C#两句。
你能不能说说我们那一楼的在吹 golang 了？
你到底是无语 go 吹，还是无语 c#黑呢？
内部错误类型应该还是要区分的，其实也是有一些办法，不过不论怎么样都是比较麻烦。 https://blog.golang.org/errors-are-values 其实类型断言也可以，就是写起来比较麻烦。标准库内部的部分细节也不是全部暴露。
1. 比如 C++ 的容器和算法，用没有泛型的语言来实现会很麻烦。对比一下 std::sort 和 qsort 两个函数， std::sort 用起来简单得多
2. 还是上面的 std::sort 和 qsort ， std::sort 的性能更好，是因为这个情况下一些函数内联的优化依赖于泛型
那就易语言吧
找到了 2015 年的采访
> Today, Rob and I lead the overall Go project at Google together.
> 我认为语言之间当然没有优劣之分，只有适合不适合。
NO NO NO ，语言自然有优劣之分。说没有只是 PC 而已，为了避免争吵。
语言有优劣之分，也有是否合适。
只是大多数流行的语言在竞争的压力下，选择了自己的专长（适用领域）。有很多语言因为“劣质”的原因，根本没有机会流行起来，或者只是流行了一小段时间。
评判语言优劣需要设定标准。有些标准是主观的，譬如说适不适合啊，是否方便阅读啊；但有些标准是可以用数理逻辑去验证的，譬如各种语言 feature 的正交性、语法二义性、语义表达能力，
在正交性方面， Lua 比 C# 的正交性好——意味着语言的各种元素、元对象的组合控制能力比 C# 来得精确。例如 lua 的 table 完全可以模拟 OO 的继承、多态；
但是 C# 的语义表达能力又比 lua 好——实现同样的抽象逻辑，使用 C# 可以写更少的代码。而 C# 如果不套用 OO 的逻辑，完全可以借助泛型和反射实现 Lua 的精确控制能力。
综上， C# 是一门比 Lua 好的语言。
当然啦，不关心细节的码农，大概是什么拿到手只要为其所用就好——就像有些人的择偶要求，女的活的，就可以了。
当人只需要满足低级需求的时候，谈什么是好的就是奢侈。
当使用编程语言只需要交货满足工程需要的时候，谈特性都是废话。
你也是这么看的吧？
当然不是。
我压根不关心特性，我只关心场景。
正好这两门语言都是我用过一段的语言。
这两语言对我而言没什么优劣。
如果写 windows 桌面程序，我肯定用 c#。
如果写用来写嵌入式的脚本，我肯定用 lua 。
c#和 lua 的生态本质上也是围绕这两个语言适合场景发展的。不存在好不好。哪怕可能有其他的第三方库 /转译器。我也不会选择。
当然，这两个场景，我都不会选 go 。
就我而言，目前的选择大概是
网页 /模板语言选择 php,这个方向放弃过 python
重接口的服务选择 go,这个方向放弃过 nodejs
嵌入式脚本选择 lua ，这个方向放弃过 js
维护脚本选择 python+shell
简单的 ui 界面选择 electron+nodejs/go,这个方向自从我换过主系统后放弃过 c#,VB 等一票
我只看某个场景适合不适合，不太考虑语言特性，甚至会放弃某些语言中比较特殊的特性。
所以 python 和 perl 我会喜欢 python
所以 nodejs 和 go 我会喜欢 go
一定要我说什么语言好的话，我会倾向与更简单通用，学习成本更低的语言。
就这么简单。
都什么年代了还拿语法特效来黑 Go 。 Go 的设计意图已经够明确了，不在乎语法优不优美特性丰不丰富，只在乎效率，不光是运行的效率还有团队的开发效率，完全就是一种对工程妥帖的选择。不然那么多创业公司用 Go 是眼瞎了嘛
不是特定语言的死忠，不想加入混战，不过还是想说一句，语言本身也是有优劣的。
比如我就认为
Swift 就比 Objective-C 要优秀很多。
Python 比 Perl 要优秀很多。
Rust 应当会比 C++优秀很多（这个没有真正用过，所以是应当）。
拒绝承认开发语言的优劣就是拒绝承认技术的进步。
混迹这么久 一直以为 jarlyyn 挺激进的 看了会儿发现 noli 更激进 形同喷子
"没有想到任何别的场合是能用的"
“自认为是码农”“降纬攻击”
“golang 吹 v2 上特别多”
“不关心细节的码农”
"夏虫不可语冰"
道德至高、下定义、贴标签 然而也没看出来能力如何
（装了逼就跑 真 TM 刺激
看了楼上的讨论，得出结论
1. Google 是傻子 ，选 Golang 写 k8s 。而不是选 C#
2. C# 强无敌，快一统江山。
3. lua 也会被 C# 干翻
你倒是很会挑对自己有利的例子。但当我拿出 QBASIC 和 GVBASIC ，你还能说出什么来么？
当然可能你只听说过 TIOBE TOP 10 上的那些语言，写过的更少，所以才得出那些结论。但我已经说过了，流行的语言已经找到了自己的适用域，所以它们才没有被抛弃。
其实你拿 TIOBE TOP 50 和 TIOBE TOP 10 比比就能得出结论了——一些语言就是没有令一些优秀。
关于语言之争，其实引起争论的原因不是语言，而是在这些语言的背后，使用这些语言的人——当你开始批评一种语言的时候，不可避免的会激怒一些使用这些语言的用户——如果这些语言有用户的话。这就是为什么会有那种 PC 式的陈述句，避免让自己暴露在非理性的漩涡中。
但是，一件东西会比另一个东西好，这是自然的，就像一个人会比另一个人优秀、一个设计比另一个设计好看一样。所以当你说“这些东西没有好坏之分”的时候，要么是在说谎，要么是在犯错。
首先指出几个问题。
1.QBASIC 和 GVBASIC 都是 basic 语言，不知道你想说什么？
2.lua 啥时候上过 tiobe top 10 了？
一个东西会比另外一个东西是自然不可能的，东西是客观存在，好与不好是每个人的主管判断，这是一个基本的哲学常识。
说 A 这个人比 B 这个人好，没有场景的话，鬼知道是什么意思？
心地好？
能力强？
人工成本低？
善于沟通？
所谓的好看，也只是好 /优秀的某一个标注而已。
你还需要好好了解这个世界
再细化一下关于你两种 basic 的问题。
说真的，在这个论坛被人义正言辞的问这个问题，真的很冷幽默。
我是 BASIC 入门的，从当年小霸王自带的 basic 开始，到 Q Basic,到 VB ，都写过一定的程序。
第一次看到把具体的语言实现当成语言本身的。 golang 还有个 gccgo 呢
按你的分法， C 是不是还分 borland c,tubor c,vc,gcc,clang?
java 是不是也要按不同的 jvm 来分为不同的语言？
c#也分.net 和 Mono?
真的很佩服你一本正经说瞎话的强大内心。
哈哈哈哈。首先题主的主题是泛型，这帖子已经不知道去哪儿了。最近在写 Golang ，我觉得泛型这种东西，有更好，没有也没什么关系。
> 一个东西会比另外一个东西是自然不可能的，东西是客观存在，好与不好是每个人的主管判断，这是一个基本的哲学常识。
不知道我理解错了没。但，你是不是在说，一个东西在客观上是不会比另一个东西好或差的，是这样么？
> golang 除了写 业务 server 之外，没有想到任何别的场合是能用的。
docker 是虚拟化场合在 Go 上的实现，只要它「能用」即可反驳上述这句话。而你又扯出什么可不可替代的概念来转移话题。
脾气真好，那个 noli 每回复一次就损你一次，连你媳妇都损上了，居然不发火
“
当然啦，不关心细节的码农，大概是什么拿到手只要为其所用就好——就像有些人的择偶要求，女的活的，就可以了。
当人只需要满足低级需求的时候，谈什么是好的就是奢侈。
当使用编程语言只需要交货满足工程需要的时候，谈特性都是废话。
你也是这么看的吧？
”
如果你是 docker 的开发者，那么你可以说这句话，然而多数人不是也很少机会用 golang 去扩展 docker 的能力。如果非要说 golang 写了 docker 能证明 golang 不仅仅在业务服务器上能用，那么我也可以说 js 可以写 os ，孤立的例子而已嘛，
只要有 os 是 js 写的，为什么你不能说 js 可以写 os?
就如同现在 js 已经可以写应用程序客户端，各平台手机 app 一样。
你自己的话说错了，怎么可以拖 js 下水？
所以我没有说过 golang 不能写别的啊，我说的就是场合。
js 写 OS 当然可以，我也没说不可以。
但我不认为 js 能写出有价值的 OS ，因为大家都不觉得 OS 领域是 JS 适合的场合。
同理，我不觉得 golang 能够有更多的地方发挥，因为：
1. 缺乏泛型支持，这也就罢了，居然支持隐式 interface 这种在别的强类型语言里面都可能当作 warning 甚至 error 的特性
2. 缺乏 OS 级别的组件化支持（例如 dll ， so 这样的），甚至 golang 自己的包管理也是一坨翔
这两点都是限制一门语言大规模使用的关键缺陷。
小业务用一下，是不错的，但 golang 不会是 better C ，最多跟 python nodejs 竞争一下。
“通用语言”这个概念本身就隐含了“解决各种计算问题的”含义；
“各种计算问题”隐含了“现实中不可能只有一个问题”，即使只有一个问题，那也必须分成多个问题才能解决；
语言的优劣就是相对于某些特定的问题表现出的相对适合性；
撇开问题域去讨论语言的优劣很没意思。很容易陷入一种混乱的攻击，这就像从一个错误的假设可以推出各种匪夷所思的结果，从没有预设的条件去推也会是这种的结果。
最近也在回头看微处理器架构、 ISA 、机器码、汇编语言、算法、编译原理，也仔细想过语言的等价性问题、形式语言、形式系统等。
有感而发，希望自己对于从图灵、冯诺伊曼以来，计算理论模型、计算系统构造者们心中所要实现的那个东西理解的没错。
所以这是你觉得，这不是个定论，这是最重要的一个前提。
你觉得 js 不能写 os
你觉得 某个语言可能比别的语言好。
这只是在你觉得的这个范畴之呢的。
“这两点都是限制一门语言大规模使用的关键缺陷。 ”
很多语言本来就不是设计出来用于大规模使用的。
典型如 lua
典型如 php
在我看来,能否被大规模使用的，和语言特性没多大关系。
比如 js 的使用规模够大了吧，是因为语言特性吗？
比如 objectC 算使用规模够大了吧，是因为语言特性吗？
语言被大规模使用的主要语言，很可能是最重要的语言，是适合的场景是不是有了爆发行的增长
至于说什么编程语言是表达人类思维抽象的工具
对不起，对于这个世界绝大部分的人来说，编程语言只是解决问题的工具。
我想不通我的思维，哪怕抽象后，能如何被任何一门编程语言哪怕表达一部分。
但其实你有没有想过，现代软件工程面对的“问题领域”其实本身很多是生安白造的概念，为了推广一些商业解决方案特意把水搞浑的。如果基于这类“领域问题”来讨论编程语言的优劣，本身就是在虚弱的理论基础上来谈的。
我举个例子（读音：再黑 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 就是好， 对 蜜汁微笑 ）
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 很大程度阻止你们使用其他模型。
说的编程语言是个层次很高的东西一样，呵呵。要秀优越很简单啊，穷车富表么，秀一下让人羡慕的生活是最好的秀优越感的吗。
我到现在也不明白，难道会或者擅长几种语言也是一个能秀优越的地方吗？你的人生不可能这么缺乏亮点吧？
gopher 是怎么也理解不了 return Either<Result, Error> 这种方式 比 return res, err 好在哪的啦，你很难让一条喜欢钻狗洞的狗，人模人样的走大门。
什么？这是面向对象？ 你说是面向对象吗？
针对“Golang Go语言与泛型：优点 or 缺陷”这一话题，作为IT领域的专家，我认为可以从以下方面进行分析：
Go语言与泛型的优点：
- 提高代码可复用性：泛型允许开发者编写与数据类型无关的通用算法和数据结构，从而减少重复代码。
- 增强类型安全性：编译器在编译时会检查泛型类型的使用情况，确保类型安全。
- 灵活性和可扩展性：泛型使得代码更加灵活，易于扩展和自定义。
Go语言在泛型支持方面的历史缺陷（现已改进）：
- 缺乏原生泛型支持：在Go 1.18版本之前，Go语言缺乏原生泛型支持，这限制了代码复用性和灵活性。开发者常使用空接口（interface{}）来模拟泛型，但这增加了代码的复杂性和运行时性能开销。
- 学习成本较高：对于新手来说，理解并正确使用接口类型来模拟泛型是一项挑战。
总结：
Go语言在引入泛型后，显著增强了其代码复用性、类型安全性和灵活性。尽管在泛型支持方面曾存在历史缺陷，但Go团队已及时改进，使Go语言更加完善。如今，Go语言已成为高性能服务器、云计算和微服务架构等领域的优选编程语言。
