V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
The Go Programming Language
http://golang.org/
Go Playground
Go Projects
Revel Web Framework
nanmu42
V2EX  ›  Go 编程语言

Go 1.18 泛型会来,但官方库支持可能得等等

  •  
  •   nanmu42 ·
    nanmu42 · 2021-10-14 16:28:00 +08:00 · 8012 次点击
    这是一个创建于 896 天前的主题,其中的信息可能已经有所发展或是发生改变。

    Rob Pike: don't change the libraries in 1.18

    大意是担心一次改得太大出错了找补不回来( Go 1 得全系列保证兼容,也不希望出现 Python 2/3 的那样的分裂情况),想先看看社区怎么用,再慢慢更新标准库。

    标准库的实验会在老地方 golang/x/exp 里展开。

    https://github.com/golang/go/issues/48918

    62 条回复    2021-10-28 18:56:47 +08:00
    Mitt
        1
    Mitt  
       2021-10-14 16:39:53 +08:00   ❤️ 2
    向后兼容是个大坑,目前官方库怎么去兼容并支持泛型都没有个合适的方案,感觉会跟 gomod 之前过渡一样产生一大堆 /v2 /v3 的后缀,写起来一大堆坑
    matrix67
        2
    matrix67  
       2021-10-14 17:19:18 +08:00   ❤️ 1
    Go 语言之父 Rob Pike 昨日发 issue:我建议我们不在 Go 1.18 的标准库中使用泛型 - https:///github.com/golang/go/issues/48918 作者的理由很简单,Go 泛型是 Go 诞生以来最大的一次语言变化,Go 1.18 版本承载了太多的 change,容易出错。并且 Go 核心开发团队也没有使用新泛型的经验,他建议 Go 核心开发团队应该多等待、观察和学习。 我是十分赞同 Rob Pike 的建议的,不要把步子迈得太大。go 应该按照自己的节奏稳步前进。


    具体可以看这个 git repo,引入进来增加了不少复杂度,go 的泛型的兼容性以及复杂性都会是比较大的问题:github.com/damonchen/go-generic-tutorial
    Rwing
        3
    Rwing  
       2021-10-14 17:21:48 +08:00   ❤️ 18
    那个啥,说句中国互联网圈子政治不正确的话,我能推荐一下 C#吗?除了内存高点,其他不比 go 差啊,甚至更强啊。
    (是的,在中国提微软的东西就是政治不正确)
    Rwing
        4
    Rwing  
       2021-10-14 17:22:20 +08:00   ❤️ 1
    欢迎来 C# 体验一下真泛型🙂
    SpiritLingPub
        5
    SpiritLingPub  
       2021-10-14 17:23:38 +08:00   ❤️ 1
    @Rwing 咋就政治不正确了,科普下,我现在就使用的.net 开发,感觉比其他的舒服多了
    nanmu42
        6
    nanmu42  
    OP
       2021-10-14 17:25:18 +08:00
    @Rwing 嗨,不存在,每个语言都有优秀的地方。
    ipwx
        7
    ipwx  
       2021-10-14 17:37:28 +08:00   ❤️ 9
    那个啥,说句中国互联网圈子政治不正确的话,我能推荐一下 C++ 吗?除了写起来复杂点,其他不比 go 差啊,甚至更强啊。
    cmdOptionKana
        8
    cmdOptionKana  
       2021-10-14 17:42:20 +08:00   ❤️ 1
    Go 核心团队性格比较谨慎、稳健,很不错。
    Glauben
        9
    Glauben  
       2021-10-14 17:45:28 +08:00   ❤️ 6
    @Rwing 不得不说一句,国内跟着微软走的程序猿,都想对它吐口吐沫吧。别说进微软,不是每个人都能进微软的。想到当年学.net 学 WP 学 XNA,每次想起来就非常的生气,浪费我好几年时间。不把开发者当人。想吃饭就别跟着微软混,随时砸你饭碗
    kidlj
        10
    kidlj  
       2021-10-14 17:47:37 +08:00 via iPhone   ❤️ 1
    @Mitt Go mod 的 /v2, /v3 是基于 semantic versioning 的主动设计好吧,被你说成了问题。
    cyrivlclth
        11
    cyrivlclth  
       2021-10-14 17:48:31 +08:00   ❤️ 1
    @Rwing 想当年我也是 C#入门的。。。现在为了恰饭,还是乖乖写 Go
    rahuahua
        12
    rahuahua  
       2021-10-14 17:48:46 +08:00   ❤️ 1
    @Rwing 后端用.NET 开源项目确实少啊,这是全世界不正确,跟中国没啥关系。微软自己的 DAPR 都用 Go 来写了
    pisc
        13
    pisc  
       2021-10-14 17:50:21 +08:00   ❤️ 1
    那个啥,说句中国互联网圈子政治不正确的话,我能推荐一下 Haskell 吗?除了写起来复杂点,其他不比 go 差啊,甚至更强啊。
    Mitt
        14
    Mitt  
       2021-10-14 17:52:04 +08:00
    @kidlj #10 /v2 /v3 是在 go mod 出来之前 gopath 的应对方案,在我看来这是个历史遗留
    kiotech
        15
    kiotech  
       2021-10-14 17:53:41 +08:00   ❤️ 1
    那个啥,说句中国互联网圈子政治不正确的话,我能推荐一下 lisp 吗?除了写起来复杂点,其他不比 go 差啊,甚至更强啊。
    tabris17
        16
    tabris17  
       2021-10-14 17:56:15 +08:00   ❤️ 1
    @Rwing 三方库太少,不能什么都自己撸吧
    xinhaiw
        17
    xinhaiw  
       2021-10-14 18:00:33 +08:00   ❤️ 2
    那个啥,说句中国互联网圈子政治不正确的话,我能推荐一下 Rust 吗?除了编译时间长点,其他不比 go 差啊,甚至更强啊。
    kidlj
        18
    kidlj  
       2021-10-14 18:04:21 +08:00   ❤️ 2
    @Mitt 关于 Go mod 的设计,Russ Cox 到今天写了 11 篇长篇博客介绍,其中关于 Semantic Import Versioning 的解释见 https://research.swtch.com/vgo-import
    inhzus
        19
    inhzus  
       2021-10-14 18:16:20 +08:00 via iPhone   ❤️ 1
    那个啥,说句中国互联网圈子政治不正确的话,我能推荐一下 brainfuck 吗?除了编译时间长点,其他不比 go 差啊,甚至更强啊。
    Mitt
        20
    Mitt  
       2021-10-14 18:28:47 +08:00
    @kidlj #18 这个确实是,我都没有了解到,不过我印象里在 vgo 出来之前 /v2 就已经有人在用了,因为当时也没有其他方案来管理版本,而且这个设计是真的不敢恭维,我不止一次因为 v1 v2 的问题踩了坑,大多数情况下依旧还是弊大于利的
    windfarer
        21
    windfarer  
       2021-10-14 18:34:01 +08:00   ❤️ 1
    @inhzus brainfuck 是开发时间长,不是编译时间长
    kidlj
        22
    kidlj  
       2021-10-14 18:38:36 +08:00   ❤️ 1
    @Mitt 可能 /v2, /v3 这种设计单拎出来看起来没有必要(仅仅为了区分 lib 的向后兼容性和多版本引入,对比其它语言的包管理方案),但它确实是 Go mod 整体设计方案的一部分,类似的还有 Minimal Version Selection 这部分的设计也和其他包管理不同,后边 Russ Cox 还上升到了软件工程的角度来思考包管理的问题。他有一个视频演讲介绍得更清楚一些,如有兴趣可以参考。
    &list=WL&index=1&t=31s
    XTTX
        23
    XTTX  
       2021-10-14 18:51:54 +08:00
    @kidlj 应该有不少人不知道 import "github.com/dimfeld/httptreemux" 和 import "github.com/dimfeld/httptreemux/v5" 的区别。只能说和常用的 npm 太不同了
    xiaofan305
        24
    xiaofan305  
       2021-10-14 18:52:22 +08:00 via iPhone
    如果要政治正确的话,我真心推荐 pualang,可以扩展你的格局,还有顶层设计思维,为你赋能从而破圈突围
    XTTX
        25
    XTTX  
       2021-10-14 18:57:05 +08:00
    为什么编程都要搞政治正确这种浪费时间的事,github 从 master 该成 main 就浪费了不少宝贵生命,它礼貌吗?它正确吗?
    chendy
        26
    chendy  
       2021-10-14 19:07:45 +08:00
    说句***的话,我 java 用 spring 全家桶一把梭不挺好么
    surbomfla
        27
    surbomfla  
       2021-10-14 19:19:18 +08:00 via Android   ❤️ 6
    帖子主题不是 go 泛型吗,为啥总是提 xxx 语言更强更好,不抬一下屁股痒是吧。
    matrix67
        28
    matrix67  
       2021-10-14 19:24:00 +08:00   ❤️ 6
    @kidlj #22 go 包版本管理吃瓜的问题不是 go mod 不好,是因为他窃取了社区胜利的果实。

    Russ Cox: 对于在 Go 1.11 里的 Go Module 的实现方式我感到非常兴奋。我上次瞅了一下最流行的大约 1000 个项目,93%的能够直接转换为 Go Module 。

    Twitter 发出来之后,Sam Boyer(dep 的主要开发者),转推了一条(后面不放英文原文截图了,可以到文章后面的连接去看):
    Sam Boyer: 最初的(旧项目到 Go Module 的)转换从来不是问题,问题是从不拿工资的贡献者们那里偷走工作成果。
    我上周 GoSF 的演讲是关于这个的。现在视频找不到了,不过我截了个图。

    Russ Cox 回复了这条推:
    Russ Cox: 我听了你的演讲。虽然我们谈了很长时间,但是明显你现在对于这一切,对于我还是感觉很受挫败,很沮丧。对此我真的很抱歉,我知道那是什么感受。

    Sam Boyer: 你能这样说我很感激。你肯定也很不容易,对于这件事造成的过分的压力我也很抱歉。
    但是这并不是你我之间的事情,我之所以在演讲中提到你,是因为你是后来社区文化和机制争论的源头。

    另一个 Go 社区的重要贡献者,Peter Bourgon 说:
    Peter Bourgon: 因为私下认识事件中的一些人,我承认我是有偏向的。不过作为一个外人看到这个事故现场,我可能以后对 Rust 兴趣更多一些了。为什么 Go 团队领导层总是拒绝从其他现代语言(的做法)中学习呢?

    Russ Cox: Go 并不是要满足所有人的所有需求。如果你喜欢 Rust 的方式,就去用 Rust 吧。我也欣赏 Rust,事实上我花了很多时间研究 Rust,Swift 中的好的地方,但是适合一个语言的未必适合其他语言。

    Peter Bourgon: 是的。但是我想不到原因为什么 go 的依赖管理没有从其他的依赖管理中学习到任何东西。我从局外人的角度来看,Go 歇斯底里的尝试不去达成任何其他人已经达成的共识,我不明白为什么要这样做。并不仅仅是你的问题。我参与了 dep 开始之前的讨论,在之前还一直在关注 glide 。我不知道为什么 go 的依赖管理社区就是不从其他(包管理)已经遇到的问题中学习。作为一个已经在提供开箱即用的工具方面证明了自己的语言和社区,我非常困惑为什么这么关键的一个部分(指包管理)几乎是刻意的设计得这么挫。
    好吧,Peter Bourgon 其实有点歪楼了。

    Russ Cox:我们是一个小团队,还有其他优先的事情要做。确实我们在这个领域晚了几年,但是事情正在往好的方面发展,几年之后再来看看我们做成什么样子。

    Matt Farina(Glide 作者)跳出来了
    你说你们是一个小团队,是因为你们把 Go 当做 Google 下面团队的一个产品,Google 这个团队是小的。如果你们创建一个社区,借助其他人的力量,那就是一个很大的团队。比如 Rust 的依赖管理团队就有不是 Mozilla 的人。
    围攻之下 Russ Cox 开启了疯狂发推模式,连发 N 条 Twitter 阐述前因后果。

    Russ Cox:
    非常有道理的批评。我们并没有处理好依赖管理的社区进程。Go 的核心团队没有今早和足够的参与这个进程,没有能够引导平滑的落地。作为 Go 的技术负责人,这是我的责任,我为此道歉。
    XTTX
        29
    XTTX  
       2021-10-14 19:44:53 +08:00
    @surbomfla <贬低其他语言 ,抬高自己用的语言和 tooling> 提供了程序员日常 15%的所有乐趣
    kidlj
        30
    kidlj  
       2021-10-14 19:52:46 +08:00 via iPhone
    @matrix67 对吃瓜不感兴趣,很高兴 Go mod 赢了✌️
    rrfeng
        31
    rrfeng  
       2021-10-14 20:59:52 +08:00
    @matrix67 没太懂,意思是社区方案( dep/glide )足够好了,也赢得了社区,然后 go mod 靠官方强势推行打败了社区方案吗?

    这个论断的前提是 go mod 没有社区方案优秀?
    bug123
        32
    bug123  
       2021-10-14 21:13:51 +08:00
    等 C++20 支持携程后就转去写 C++
    FrankAdler
        33
    FrankAdler  
       2021-10-14 21:28:14 +08:00 via iPhone   ❤️ 1
    等就等呗,多蛋疼一段时间
    runze
        34
    runze  
       2021-10-14 21:44:33 +08:00   ❤️ 2
    @rrfeng #31
    起初官方不做,社区出了一大堆解决方案,著名的有 godep 、glide 。
    然后有了一个“官方”的解决方案:dep 。
    但是一年半以后,又出了个真正的官方解决方案:go mod 。
    iyear
        35
    iyear  
       2021-10-14 22:00:11 +08:00   ❤️ 1
    谨慎点好,别太激进成了第二个 python
    matrix67
        36
    matrix67  
       2021-10-14 22:21:51 +08:00   ❤️ 8
    @rrfeng #31

    简单的总结一下

    Russ:我有管理责任,我道歉。dep 一开始就不是作为官方实现,是个实验,你们想多了。我想要 sementic import versioning,dep 不支持,所以没法把 dep 集成到 go 中。现在我搞了 go module Proposal 和原型实现(vgo),大家都说好。

    dep 的开发者:

    当 dep 委员会成立的时候,我竭尽所能的,让它以及它推进的工作,尽可能的可靠和无懈可击,以保护工作组的信用,工作组成员的声誉,以及产出的产品的有效性。为了代替自核心团队的指导,甚至基本的交流,我们决定:
    - 从社区的领袖和专家中征集成员
    - 成立一个次级的顾问组支持所有相关的项目
    - 花费了半年时间收集用户反馈和进行领域内的研究
    - 详细 Review 了所有其他有意义的包管理工具
    - 步调一致的进行设计,目标在所有的主要决策上达成一致
    - 所有的一切,都煞费苦心的,公开的记录文档

    我们做了所有的这一切,因为我们想要成为社区能够更近一步,解决一直被核心团队忽视的问题的典范。我无法找到比我们比我们所做过的事情更好的事情了。但是结果,这些努力就像我们从来没有做过任何事一样:核心团队最终不参与进我们所贡献的成果上面,而是坚持自己完成,本质上一个全新的重头开始的项目。

    我想 dep/vgo 的结局很好的说明了,虽然 Go 领导层很乐意接受对 issue 和无争议的 Proposal 这样的贡献,但仍然在与大规模的自主自治的贡献者斗争。权利掌握在 Google 的核心开发团队里。

    如果有一天我做关于这个最终失败的项目的演讲,我要在最后放一页幻灯片,上面有一个图,一艘船在岛上失事了,船长说: "你生命的意义就在于警告其他人"。我希望这个故事给别人一个警告:"如果你有兴趣对 Go 做出大的实质性的贡献,独立的勤奋工作不能补偿你那不是来自核心团队的设计"。


    ----
    Addendum(作者看完在 Reddit 上的讨论添加的):
    这次引发的讨论启发了我。我想我对于发生的事情,有了更好的全景的视角。我认为 dep 团队和核心团队各自有完全不同的对对话的理解,直到 vgo 文章的出现让量子态塌缩了。

    Dep 团队相信 dep 和之前出现的工具是不一样的,是一个经过研究和详细考虑,社区驱动的最终 go 依赖管理解决方案。核心团队认为 dep 和之前的工具本质上是同一类,是他们设计的最终的方案的前奏的一部分。

    我相信 dep 团队很清楚他们的地位,能够从核心团队的表述中能够看出来是处于什么样的地位的。但是明显(dep 团队成员)没有能够普遍的理解这个地位,直到为时已晚,直到已经太晚。唉,事后来看是很显然的事情,但是当时谁又能够看得透呢?
    rrfeng
        37
    rrfeng  
       2021-10-14 22:33:19 +08:00 via Android
    @matrix67
    @runze
    感谢
    lvdb
        38
    lvdb  
       2021-10-14 22:51:39 +08:00 via Android
    那个啥,说句中国互联网圈子政治不正确的话,我能推荐一下 js 吗?写起来不复杂,也不比其他任何语言差,还可以全端一把梭,不香吗?人生苦短,我选 js 。
    janxin
        39
    janxin  
       2021-10-14 23:21:24 +08:00 via iPhone
    @lvdb 那应该推荐 ts,还有 deno 引擎可以用
    agagega
        40
    agagega  
       2021-10-14 23:48:47 +08:00 via iPhone   ❤️ 1
    Go 其实有点像 Google 的其他若干技术,比如 Bazel 、Kubernetes 、清教徒风格的 C++ style guide (还有很多一下想不起来了),也许很适合 Google 内部的一些场景,但在其他方面可能就会让人难受。
    stevenhawking
        41
    stevenhawking  
       2021-10-15 00:51:33 +08:00
    那个啥,说句中国互联网圈子政治不正确的话,我能推荐一下 php 吗?虽然没有泛型但写起来不复杂,也不比其他任何语言差,还可以全端一把梭,不香吗?人生苦短,我选 php 。
    iseki
        42
    iseki  
       2021-10-15 01:09:24 +08:00
    那个啥,说句中国互联网圈子政治不正确的话,我能推荐一下 kotlin 吗?虽然编译缓慢 gradle 更慢,但抱着 JVM 大腿生态问题不大,想尝鲜还有 coroutine,这东西某种意义上做的比 go 的 goroutine 好。更何况空安全啊等等各种漂亮的语法极大降低脑细胞阵亡概率。
    lxml
        43
    lxml  
       2021-10-15 01:16:16 +08:00 via Android   ❤️ 1
    go 在 dep 问题上处理确实欠妥,不过我喜欢的就是 go 跟 ios 似的,加东西瞻前顾后,先提供少量精华特性,再慢慢往上加,反观 某 js,除了糟粕就没多少精华了
    lvdb
        44
    lvdb  
       2021-10-15 09:00:55 +08:00 via Android
    @janxin 当然此处的 js 指用了 ts 的 js 呀
    lvdb
        45
    lvdb  
       2021-10-15 09:01:45 +08:00 via Android
    @stevenhawking 你们拍 h 片并不可以全端啊,写个移动端 app ?
    lvdb
        46
    lvdb  
       2021-10-15 09:03:07 +08:00 via Android
    @lvdb 不过 php 的确写起来好快啊,改起来也快🥲
    qq1340691923
        47
    qq1340691923  
       2021-10-15 09:25:42 +08:00
    @stevenhawking 弱类型语言要啥泛型?
    Rwing
        48
    Rwing  
       2021-10-15 10:05:55 +08:00
    @rahuahua 世界范围内并不少,比 go 高 3-4 倍左右,是 java 的 1/2 左右,可以参见 jetbrains 的调查数据
    @tabris17 如果一个语言三方库太少,他都活不到 2021 年,C#不缺少任何库,无非就是多少的问题,例如 java 的 json 解析库有 5-6 个,C#可能有 1-2 个
    janxin
        49
    janxin  
       2021-10-15 10:10:28 +08:00
    @lvdb 不过一般我对其他语言用户都是推荐 CoffeeScript
    FightPig
        50
    FightPig  
       2021-10-15 10:56:50 +08:00
    相比 go 我真的喜欢 rust,但编译起来 实在比 go 慢太多,而且每次 target 目录太大了,
    yx1989
        51
    yx1989  
       2021-10-15 10:59:00 +08:00   ❤️ 1
    @ipwx C 渣渣就算了吧,除了没有 GC 性能可能好一点点。写的慢,编译慢;浪费青春,浪费生命。

    编码 5 分钟,修 core 2 小时(如果顺利的话)。项目大一点,编译时间巨长。
    ipwx
        52
    ipwx  
       2021-10-15 11:16:07 +08:00
    @yx1989 写得快,编译慢。编译慢倒是事实,得特别小心头文件嵌套……

    但是写得慢,恕我直言,我怎么没这种感觉? C++ 写起来很爽的,特别是算法,没有模板和零开销抽象写个锤子的算法?另外只要不含界面的东西,C++ 写起来也都挺好用的,只要你花点时间写个比如 1 万行的基础库屯着。
    ZSeptember
        53
    ZSeptember  
       2021-10-15 11:16:50 +08:00   ❤️ 1
    影响不大,放到 exp 也是可用。
    主要加了泛型,自己写库爽多了
    yejinmo
        54
    yejinmo  
       2021-10-15 14:31:16 +08:00
    都 2021 年了怎么还有一提 .NET 就微软的
    .NET 早就开源给了 .NET 基金会
    .NET 基金会是独立运作的组织
    fakeshadow
        55
    fakeshadow  
       2021-10-15 17:54:51 +08:00
    主题: xxx
    回复: me me me
    ChrisFreeMan
        56
    ChrisFreeMan  
       2021-10-15 22:21:46 +08:00 via iPhone
    chenqh
        57
    chenqh  
       2021-10-16 16:45:01 +08:00
    @Rwing C#主要是一开始绑定死了 windows,不支持 linux 呀,语法再好,不支持没有办法呀,不想 golang,一开始就是全平台
    rahuahua
        58
    rahuahua  
       2021-10-17 11:30:45 +08:00
    @Rwing 说的是开源基础项目,不是指业务,云原生基本就是 Go+Java 的市场了。做业务没必要有歧视,公司选择自然有自己的考虑,中国选择 Go 也没问题。
    crclz
        59
    crclz  
       2021-10-17 12:37:31 +08:00
    预言:如果 golang 加入泛型,那么 golang 的工程能力(团队生产力)会被削弱。
    如果要增强一个语言(例如 java )的工程能力(团队生产力),那么请在框架部分启用全部特性,然后在除框架以外的部分禁止团队成员使用泛型、继承等特性。
    sampeng
        60
    sampeng  
       2021-10-18 11:04:22 +08:00
    相比 GO 更喜欢 rust 。。。解决了绝大部分的事情。。除了编译太慢没什么其他缺点。
    INCerry
        61
    INCerry  
       2021-10-28 18:17:20 +08:00
    @chenqh 那是好多年前的事情了 C#早已跨平台
    chiuan
        62
    chiuan  
       2021-10-28 18:56:47 +08:00
    泛型真的这么有必要吗!?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5450 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 39ms · UTC 08:34 · PVG 16:34 · LAX 01:34 · JFK 04:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.