|
|
@@ -6,7 +6,7 @@ draft: false
|
|
|
|
|
|
## 问题描述
|
|
|
|
|
|
-在描述问题之前,简单说一点背景知识
|
|
|
+在描述问题之前,简单说一点背景
|
|
|
|
|
|
### go mod import 机制的简单描述
|
|
|
|
|
|
@@ -73,18 +73,16 @@ go mod 从某种程度上可以看作 Golang 的包管理子系统,凡是使
|
|
|
|
|
|
基本不外乎这几种方式,当然 Golang 和这些语言的包管理有一个很大的不同,那就是 Golang 没有自己专属的包服务器,比如 Python 的 [pypi.org](pypi.org);而是借助与 github.com。
|
|
|
|
|
|
-这有几点问题,因为我 github.com 不是为你 Golang 包管理设计的,但因为 github.com 的灵活性和广泛的支持度,这不是大问题,只是需要 Golang mod 的作者按照约定的规则对提交有针对性的处理一下。
|
|
|
+这有几点问题,因为 github.com 不是为 Golang 包管理设计的,但因为 github.com 的灵活性和广泛的支持度,这不是大问题,只是需要 Golang mod 的作者按照约定的规则对提交有针对性的处理一下。
|
|
|
|
|
|
另外,Golang 代码的 push 同时也意味着包发布,这可能并不是某些作者希望的。
|
|
|
|
|
|
使用 github 作为包存放服务器不是问题,因为没几个人喜欢千篇一律的世界,这种想法以及想法的实施非常重要。 出现 fork 问题的重要原因还是因为对子路径的依赖,对子路径的依赖可能从某些角度出发是必要的,当最终它绝对不是必要的,所有的理由都是借口。
|
|
|
|
|
|
-就比如 Golang1.8 将要出现的泛型,语法大致如 `func [T]foo(a, b int) T {}` 没错,泛型变量使用 `[]`,当然开发团队还是有理由,非常合理的理由,总之会造成歧义。C++,Java,C# 哪个语法复杂度不必 Golang 高?但用`<>`就不会解析出歧义。于是,几乎是历史首次:泛型不以 `<>` 来标识,用云风的话来说:就用你们的眼球,来 parse 这些代码吧!同时我不得不认为:Golang 语法简洁的最终要原因是他们工程师团队没有能力解析更复杂的语法。
|
|
|
+就比如 Golang1.18 将要出现的泛型,语法大致如 `func [T]foo(a, b int) T {}` 没错,泛型变量使用 `[]`,当然开发团队还是有理由,非常合理的理由,总之会造成歧义。C++,Java,C# 哪个语法复杂度不必 Golang 高?但用`<>`就不会解析出歧义。于是,几乎是历史首次:泛型不以 `<>` 来标识,用云风的话来说:就用你们的眼球,来 parse 这些代码吧!同时我不得不认为:Golang 语法简洁的重要原因之一是他们工程师团队没有能力或懒得解析更复杂的语法。
|
|
|
|
|
|
## 最后
|
|
|
|
|
|
Golang 是一个很优秀的语言,他的优秀的重要原因是内置 goroutine 和 channel 以及支持多核的 goroutine 调度器,强类型的编译型语言,简洁的语法设计。这几点使 Golang 具有无限的潜力。
|
|
|
|
|
|
-同时,Golang 也有一些不足(每个人都可以说一罗筐),在包管理和泛型标识这些理应很基本的问题上出现意外,对于 Golang 团队来说,显得太业余了。
|
|
|
-
|
|
|
-这些人太善于找理由了,我喜欢看到的做法是:他应该是什么样,就必须是什么样。
|
|
|
+同时,Golang 也有一些不足(每个人都可以说一罗筐),在包管理和泛型标识这些理应很基本的问题上出现意外,对于 Golang 团队来说,显得业余了。
|