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

[月经贴] golang 能否完全替代 c++?

  •  
  •   wangyzj · 2020-05-25 02:01:13 +08:00 via iPhone · 17357 次点击
    这是一个创建于 1422 天前的主题,其中的信息可能已经有所发展或是发生改变。

    不考虑 c,只考虑 c++

    不考虑嵌入式

    先说我的个人观点

    我觉得能。虽然性能略逊,但研发协作效率更好

    我也是 golang 萌新,大家再来各抒己见吧

    第 1 条附言  ·  2020-05-25 11:28:09 +08:00
    半夜仍一条
    早上一大堆消息
    真刺激

    首先,我不是安利 go,纯讨论

    c++肯定有很多优点,比如楼下不断提起的泛型,但也不能否认其缺点
    go 的缺点楼下提到的也很多,比如 gc,但我是觉得从某个角度来说,gc 减少了复杂度

    至于楼下说的 c++游戏行业是霸主,我不是游戏行业的,我不评价

    我重点还是看研发效率和运行效率的平衡

    还有楼下提到的内存敏感和系统底层,我更推崇 c,所以我最开始就说了,只看 c++
    第 2 条附言  ·  2020-05-25 11:34:28 +08:00
    楼下很多提到 rust

    我虽然没看过 rust,但我知道 rust 是底层非常好的语言
    其实本帖标题换成 rust 也可以
    142 条回复    2020-06-16 15:06:53 +08:00
    1  2  
    thisismr2
        101
    thisismr2  
       2020-05-25 15:03:46 +08:00
    不能. go 有很多局限性. (展开需要打很多字, 暂不展开)

    另外正义提到 c 和 c++, 就从另外一个角度谈下,
    从不同编程人员不同的思维方式来说,
    有的团队(成员)的思维方式 适合来共同用 c 写项目,
    有的团队(成员)的思维方式 适合来共同用 c++写项目,

    每一种语言都会带来一种思维方式. 如果这个思维方式和编程人员的思维方式契合(相等或被包含), 则适合此编程人员用, 否则则不适合.

    比如 C 之后, 接触并用了很久的 java, 觉得 java 太强大, 太 design 了, 太完备了, OO, 范型, 继承的各种概念. 简直完美(也有本书叫完美 java 编程), 后台接触了 python, 开始用 python, 觉得很舒服, 至少在所需场景下可以完成相同的目的, (私以为*大部分情况下[没说全部]*性能是第二考虑因素, 如果多加一个机器, 能让我愉快的编码也不错)

    所以如果在适用场景重叠的情况下, 选择喜欢的挺好

    比如有人喜欢 typescript 的类型, 有人喜欢 js (包括愚蠢的我现在还不会用 const let)
    TransAM
        102
    TransAM  
       2020-05-25 15:08:28 +08:00
    @hankai17 goroutine 只是 n:m 的线程模型,这个只是系统线程( Thread )和任务 /回调( Runnable/lambda )的对应关系,我用个线程池照样可以啊。
    TransAM
        103
    TransAM  
       2020-05-25 15:09:57 +08:00
    @xpresslink 这个要看引擎支持不支持,但我估计很难说服引擎开发者。你看,python 多火,没说服 c2dx 也没说服 u3d,golang 更别想了。
    wangyzj
        104
    wangyzj  
    OP
       2020-05-25 15:16:57 +08:00
    @TransAM 开发游戏的确太依赖于生态了,现在引擎就那么几个,基本都 c++,用 go 不是不行,但是开发者未必乐意
    wangyzj
        105
    wangyzj  
    OP
       2020-05-25 15:20:51 +08:00
    @thisismr2 #101 其实我这个问题问的比较极端了,我后来也发现了,但是为时已晚
    实际上我主要是考虑写应用 go 是可以的,效率高,但是呢,他和 java 又不太一样,不是字节码
    但是比较 c++的确也有很多不合适
    tmac33
        106
    tmac33  
       2020-05-25 15:22:02 +08:00
    你是否想问,Rust 能否完全替代 C 艹?
    blless
        107
    blless  
       2020-05-25 17:20:21 +08:00 via Android
    @wysnylc #95 别问了,又想起一堆各种 String 操作下会有什么结果的笔试题…
    Go 就省事多了
    wysnylc
        108
    wysnylc  
       2020-05-25 17:24:06 +08:00
    @blless #107 那你还是没懂
    owenliang
        109
    owenliang  
       2020-05-25 17:32:23 +08:00
    实时性 go 是不行的。
    iceheart
        110
    iceheart  
       2020-05-25 19:13:24 +08:00 via Android
    @MarkLeeyun #92
    我的确看过,虽然只是一小部分。
    我在 linux 下用的和安卓下用的 chromium 都是源码编译的,所以我确定没有一行 go 代码
    cmdOptionKana
        111
    cmdOptionKana  
       2020-05-25 19:57:39 +08:00 via Android
    看楼主附言,明显楼主还是不明白有 gc 与没 gc 的根本性区别。
    Torpedo
        112
    Torpedo  
       2020-05-25 20:01:25 +08:00
    c++底子太厚了。谁也不能全替代
    jin7
        113
    jin7  
       2020-05-25 21:28:14 +08:00
    都是说要取代 c++ 十多年了还没被取代
    gansteed
        114
    gansteed  
       2020-05-25 21:31:46 +08:00
    各有优劣吧
    Hanggi
        115
    Hanggi  
       2020-05-25 21:34:17 +08:00
    最后可能替代 C++ 的目前只有 Rust 。
    Go 更偏向应用层,网络层。
    wangyzj
        116
    wangyzj  
    OP
       2020-05-25 21:58:19 +08:00 via iPhone
    @cmdOptionKana #111 谢谢你的回复,你自己没理解上去就请闭嘴吧
    tianshilei1992
        117
    tianshilei1992  
       2020-05-25 22:51:27 +08:00
    GC 这一点就够了…😂
    dayeye2006199
        118
    dayeye2006199  
       2020-05-26 00:47:39 +08:00
    高性能计算 gpgpu 还是一堆 cpp 和 c,暂时 go 没法吃这块蛋糕
    TransAM
        119
    TransAM  
       2020-05-26 00:53:32 +08:00 via Android
    @wysnylc 不可变类型就是不可变类型,讨论不可变类型是值类型还是引用类型是无意义的。
    CoderGeek
        120
    CoderGeek  
       2020-05-26 01:32:36 +08:00
    不能。
    Lightbright
        121
    Lightbright  
       2020-05-26 01:53:24 +08:00 via Android   ❤️ 1
    Chromium 项目七成安全漏洞属于内存安全问题

    Chromium 项目报告,它七成的严重安全 bug 属于内存安全问题,因此它的下一个项目将是在源头阻止此类 bug 。对 2015 年之后发现的 912 个高危级安全 bug 的分析发现,七成为内存不安全问题,如 C/C++ 指针错误,其中一半是使用后释放 bug 。这些 bug 遍及整个代码库,非安全性的 bug 很大一部分其根源也是内存安全问题。Chromium 项目称它的沙盒机制在设计时就考虑了此类 Bug 的存在,但现在沙盒和网站隔离机制已经达到其能力的极限。他们现在考虑的一个方案是使用现有的更安全的语言如 Rust 和 Swift 等。Media

    www.solidot.org/story?sid=64457

    楼上是谁说 Chrome 为什么不用 Rust 的?这不是来了?
    tao147258
        122
    tao147258  
       2020-05-26 08:21:40 +08:00 via iPhone
    小心大道至简
    fovecifer
        123
    fovecifer  
       2020-05-26 08:56:21 +08:00
    为什么这么多人不提 GC 呢?很多场景下对 GC 的容忍性很低,所以 C/C++这种具有很大的优势

    PS:同时也是很大的劣势。。。
    suckli
        124
    suckli  
       2020-05-26 09:23:37 +08:00
    看领域

    Go 在大部分领域都能工作的很好
    国内大部分 C/C++程序员,在内存管理方面掌握的都不是很好,我在项目中遇见过的大部分问题,都是由于内存管理引起,而且极难定位。

    前两天看了一份报告,说是 Google Chrome 的大部分问题也是内存问题
    Go 在这方面可以很好的 cover 住,能够避免大部分内存问题。

    在这一点上,从管理层面来说,就是一个巨大的优势。

    除非对时延,性能等要求极高的领域,Go 可能就不适合了。
    learningman
        125
    learningman  
       2020-05-26 10:14:53 +08:00
    别吵了别吵了,再吵大家一起用回汇编吧,实在不行还有穿孔纸带嘛
    hikkikuma1991
        126
    hikkikuma1991  
       2020-05-26 10:57:43 +08:00
    不能
    dbskcnc
        127
    dbskcnc  
       2020-05-26 11:10:17 +08:00
    gc 和 非 gc 显然就不是同一个赛道, 不过在 pc/后端网络和应用层面,go 确实可以处理大部分的事情
    wangyzj
        128
    wangyzj  
    OP
       2020-05-26 11:47:59 +08:00
    @suckli #124 其实你这个答案契合我的意思
    但是我问题没问好
    结果就成了喷
    flikecn
        129
    flikecn  
       2020-05-26 12:01:08 +08:00
    存储领域还是需要 C++,GO 胜任不了
    mutalisk
        130
    mutalisk  
       2020-05-26 12:27:03 +08:00
    一个依赖于 runtime 的语言是无法开发第三方库供其他语言调用的
    libook
        131
    libook  
       2020-05-26 12:43:22 +08:00
    Go 在三四年前开始推广的时候有这么一条信息:“Google 希望在内部的一些场景使用 Go 语言来代替 C++进行开发。”
    然后这个信息就被各大媒体歪曲成了“Google 公司:Go 语言势必取代 C++。”

    实际上当你深入了解这两门语言之后,你会发现,这两门语言区别非常大,就好比是“用高铁来取代跑车”一样荒谬,实际上 Google 的 C++开发者在这种舆论上也都很懵逼,纷纷发言说用 Go 在大多数应用场景上取代 C++是无稽之谈。

    抛开应用场景谈语言好坏都是耍流氓。虽然 Go 语言一开始是以“系统开发语言”作为定位的,但当前除了 Docker 生态以外,Go 基本上都是活跃在网络服务的开发方面,在微服务领域基本上已经成了御用语言之一,比起早先用 C++开发的高性能网络服务,Go 语言确实能够在保障较高的性能的同时极大地提升开发效率。

    选语言不是选归宿,一个优秀的技术人员应当是博爱的,在任何场景下都能做出最合适的技术选型,避免“黔驴技穷”。

    P.S. 吐槽 V 站上的另一个说 Deno 取代 Node.js 的帖子,和 Go 与 C++的情况如出一辙。
    17701762115
        132
    17701762115  
       2020-05-26 12:47:20 +08:00
    wangyzj
        133
    wangyzj  
    OP
       2020-05-26 13:04:00 +08:00
    @libook #131 这是个好回答,我觉得就是一个运行效率和研发效率选型的问题,我之所以说替代 c++主要是因为我标题写的不好,其实底层高运行效率我会选择 c
    至于 deno,没研究过,短期来看应该是不可能
    timothyye
        134
    timothyye  
       2020-05-26 13:28:34 +08:00 via Android
    Go 不能,Rust 我看行
    libook
        135
    libook  
       2020-05-26 14:55:55 +08:00
    @wangyzj
    一般来说(不考虑特例),写一个具备一定功能的程序的话:C++要比 Rust 简单,但是 Rust 要比 C++可靠;未经过优化的 Rust 程序可能会比 C++程序性能好,但是 C++的优化天花板更高。
    Rust 的可靠是建立在其语言上对于安全代码的约束的,自然不如 C++灵活,但同时 Rust 也给开发者提供了选择的余地,如果偶尔要求灵活度也可以使用 unsafe 来牺牲可靠性。

    但是很多高度复杂的项目团队都希望把难点留在开发阶段,而不是运营阶段的 Debug,这块就是 Rust 的市场。
    数据库、中间件、区块链、容器(或沙盒、虚拟机)、WebAssembly 等已经开始出现基于 Rust 开发的产品(包括我#131 提到的 Deno ),随着 Rust 的不断完善和发展,势必会从 C++的应用场景中接管不小的一部分。

    所以同样的,看你项目上的首要痛点究竟是啥,在都能实现的条件下,如果痛点是可靠性那就选 Rust,如果痛点是性能就用 C/C++;同时也可以模块化处理,Assembly 、C/C++、Rust 、Python 、JS 一起,物尽其用。
    wzw
        136
    wzw  
       2020-05-26 16:15:48 +08:00
    我写 有些用 Python, 有些用 Go, 目前觉得 Go 挺好
    hankai17
        137
    hankai17  
       2020-05-26 19:25:07 +08:00 via Android
    @TransAM 我讲的是 c 的回调效率很高 而 go 要做到回调的效果是通过 schedule 恢复上下文
    zhixi
        138
    zhixi  
       2020-05-26 19:35:32 +08:00
    golang 成也 gc,败也 gc
    ww2000e
        139
    ww2000e  
       2020-05-26 19:37:20 +08:00
    感觉会有越来越多的 c++项目换 rust
    byaiu
        140
    byaiu  
       2020-05-26 23:49:58 +08:00
    @suckli 想请教一下您遇到的 C++的代码规模是怎样的?
    exhades
        141
    exhades  
       2020-05-27 01:16:53 +08:00
    rust 天下第一
    suckli
        142
    suckli  
       2020-06-16 15:06:53 +08:00
    @byaiu 百万行
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   4697 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 10:07 · PVG 18:07 · LAX 03:07 · JFK 06:07
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.