Go

Go语言自开源至今已经11个年头了！截至本文发稿时，目前最新的Go版本为1.15，Go核心开发团队正紧锣密鼓的进行着Go 1.16版本的开发（现阶段主要是修复bug），该版本将在2021年2月份正式发布。 Go以“自带电池(battery included)”而为人所知，除了Go标准库的全面和强大之外，Go工具链的丰富和易用在主流编程语言中也是位列“执牛耳者”之列的，而Go文档查看工具就在Go工具链之列中。 ...

2020年最后一个购物狂欢，双十二购物节“Gopher部落”知识星球推出双十二优惠！本年度最低折扣仅限今天一天。笔者建立“Gopher部落”旨在建立一个高质量的Go语言技术精品社区，持续不断的高质量技术资料分享，让加入的星友每天都有新收获！欢迎大家加入！ Go 1.16将于2021年2月发布。目前已经进入freeze状态，即不再接受新feature，仅fix bug、编写文档和接受安全更新等。 ...

这篇文章的初衷是想解答知乎上的一位知友提出的问题。没想到完成一种实现后，这个问题居然被删除了。那么既然实现了，就分享出来吧。问题的原文找不到了，问题大致是这样的： 一个程序中存在多个函数调用链都调用了函数D： A1 -> B1 > C1 -> D A2 -> B2 > C2 -> D A3 -> B3 -> C3 -> D ... ... 那么，如果某次函数D被调用时出现了问题，那么怎么知道这个D是哪个函数调用链里的D呢？ 有些gopher可能会说通过Delve在线调试打印函数调用栈可以知晓D的调用链，还有些gopher可能会说通过各个函数中输出的业务日志可以查明出问题的D归属的函数调用链，这些都是可行的思路。 ...

如果您还在使用vendor机制管理依赖包，那么说明您肯定是处于下面两种情况之一！ 还工作在传统的GOPATH模式下(使用Go 1.10及之前版本；或Go 1.11及之后版本，但GO111MODULE=off)，利用vendor管理目标包的特定依赖； 工作在go module模式下，但仍然利用vendor管理目标module的特定依赖并使用go build -mod=vendor来构建。 那么我们是否应该将项目中存储依赖包的vendor目录提交到源代码仓库进行管理呢？如果让笔者给出答案，那就是：应该。 ...

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中！本专栏主要满足广大gopher关于Go语言进阶的需求，围绕如何写出地道且高质量Go代码给出50条有效实践建议，上线后收到一致好评！78元简直就是白菜价，简直就是白piao! 欢迎大家订阅！ 本文翻译自《GO — The TESLA Of Programming World》 – https://medium.com/globant/go-the-tesla-of-programming-world-a3ad8584723e。内容有改编。 免责声明：本文的内容仅用于娱乐和提供信息。我强烈建议读者不要基于这篇文章来进行专业领域的决策。这里表达的观点仅是作者本人的观点，绝不代表作者所属任何组织的观点，思想或意识形态。 ...

本文首发于我主持的“Gopher部落”知识星球，欢迎大家加入星球，一起学习Go语言！年底前8.8折优惠，不要错过哦！ 2020年11月22日，Go核心开发团队技术负责人Russ Cox在golang-dev论坛上确认了Go泛型将在Go 1.18落地(2022.2)： 这对于那些迫切期盼go加入泛型的gopher来说无疑是一个重大利好消息！不过，泛型是把双刃剑！泛型的加入势必会让Go语言的复杂性大幅提升。我很是担心Go加入泛型后会像C++模板那样被“滥用”而形成很多奇技淫巧，这显然不是Go项目组想看到的。因此他们现在在宣传泛型时都是比较谨慎的。Robert Griesemer在GopherCon 2020大会上演讲“Typing [Generic] Go”中明确给出了Go泛型的使用时机： ...

本文首发于“Gopher部落”知识星球！ 切片是Go语言中引入的用于在大多数场合替代数组的语法元素。切片是长度可变的同类型元素序列，它不支持存储不同类型的元素，当然如果你非用**sl := []interface{}{“hello”, 11, 3.14}**来抬杠^_^，那就另当别论。 ...

考虑了很久自己要不要开一个知识星球？自己并不擅长社群运营，但 自己的技术内容输出档次又是不错的且是持续的，能让一定范围的朋友感觉是有价值的； 面对大家的问题，相信自己的知识和经验储备也能给出很具参考价值的答案； 并且这样的一个知识付费的产品还能反过来督促自己输出更多、更有价值的内容，何乐而不为！ 于是鄙人下载了知识星球的app，大胆地点击了“创建星球”，**“Gopher部落”**这颗星球就这样诞生了！ ...

我们见到的Go包的导入路径常常以github.com、bitbucket.org等代码托管站点的域名为前缀，这样的包导入路径有一个问题，那就是当Go包的托管站点发生变更时(比如从github.om迁移到bitbucket.org或gitlab.com)，该包的使用者需要更新包的导入路径。当然，在支持go module+GOPROXY的情况下，如果使用者不再升级包版本，他/她完全可以继续使用原包导入路径，但这仅是特例。 还有一些包的导入路径并非以知名代码托管站点域名作为前缀，比如：Go官方扩展包text，它的包导入路径是golang.org/x/text，这种包导入路径被称为vanity import path，字面义是虚荣心导入路径，即以个人或组织官方域名作为前缀的包导入路径。采用vanity import path的包避免了包迁移对包使用者的影响。包使用者完全无需关心包的实际存储位置是在github上还是在bitbucket上或是私有服务器上。同时将vanity import path作为包的权威路径(canonical import path)，也方便go get等对包权威路径的检查，避免包路径变更的前后不一致。 ...

提到HashiCorp这个公司，可能很多人都没听说过。但提到vagrant、consul、nomad、terraform或者vault，那么你一定对这些工具或其中之一有所耳闻。这些工具都是HashiCorp这家公司的开源项目。 今年年初，HashiCorp在中国IT圈着实“火”了一把！当时HashiCorp宣布旗下软件禁止在中国区销售，这让很多重度依赖欧美主导的开源软件的国内大厂、小厂、传统IT公司以及IT化做的比较好的大型国企“惊出一身冷汗”。但事后证实只是HashiCorp旗下的企业软件禁止在中国区销售，开源版本不受影响。并且企业版软件禁售的原因是因为其下产品Vault的加密方式不符合中国当地法律要求，为了遵循当地法律，所以禁止销售。 ...