为什么 Go 语言能在中国这么火？-CSDN博客

在知乎的一个问题为什么 Go 语言能在中国这么火？ https://www.zhihu.com/question/46755408/answer/586812009 的回复, 整理后发在这里了

嚯哈, 很让我欢乐的一个副标题------------- 截图自ReadHub 开发者资讯, 挺让人喜欢的一个智能聚合网站

1. 因为 "golang并没有颠覆性解决问题",只是, 简单, 学习简单

1.1 太阳底下没有新鲜事, 历史总是在"重复"

当年写 CGI , php 打败了 perl , 无他, 在 web 的 CGI 时代, php 学习成本低.

同样 , 2018年 vueJS 与 react 相比更为"火", 无他, vuejs 学习成本低.

go 相对于 java 也有点类似, 学习成本低.

好几年前, 游戏开发, erlang 在后台来说, 那是中坚力量, 而这两年, go 作为游戏开发的后台, 也不少了吧.

也一样, 相对 erlang , golang 学习成本低.

1.2 "其实有多大差别啊", 对头, 只是一些小差别, (业务逻辑)伪代码相同情况下, go 代码简单,易读(易维护)

有答主说了 "其实有多大差别啊，搬砖而已" ---------> 我同意这句话, 但也不完全同意这句话

同意的地方是, 对于传统业务, 尤其是企业级应用或业务, 以及有明确终端用户的业务来说, 在不考虑量级情况下, 业务实现流程与处理约束有相似之处, 开发实现也有相类似之处.

所以, 不同语言/架构开发来说, 差别不明显, 比如说, 用户管理 / 资费交割/ 业务鉴权 / 商品管理都差不太多( 这里没说内容管理, 内容差别太大, 但商品管理差别不会大) .

这里说的业务量级, 指的是用户总量, 并发量, 业务运行随时间累积的数据总量与有效数据集总量

比如大型网店, 下架后的商品数据, 对于网店销售来说, 属于失效数据集, 但对于销售行为分析等大数据估算来说, 是有效数据集)

对于这些, 不同语言开发, 就是搬砖.

那搬砖有什么不同呢, 无他, 人不同罢了:

每个人都趋向于选择自己熟悉的工具.
研发经理/产品经理趋向于容易招聘, 按量交货(坑少的), 而且薪水还低的人

1.3 "并没有颠覆性解决问题", 是的, go 只是尝试着, 简单,轻松的去解决,没有黑魔法,很少语法糖,甚至,没有泛型(也许,将来会有...)

有朋友说了, "golang并没有颠覆性解决问题", 没错, go 能解决的问题, java 也能,甚至解决得更好. --------> 所以, 只是同样的"搬砖而..."

但, 砖与砖还是有差别. 对于开发量在 100人月上下的项目, 同样的业务管理( 是的, 我带队实施过, 设计用户总量10万计, 每月新增用户量3000到10000, 每天开机量90%, 业务模型/技术架构一样, 这里的技术架构, 指的是业务子系统划分/ 中间件/数据库模型基本一样, 尤其是各子系统/各业务单元之间的接口完全一致, 见注1), go 实现要比 java , 在部署/运维上, 成本要降很多.

同样是本科毕业2年内的开发人员, go 只要基本业务测试通过, 性能与稳定性, 比 java 要好. 至于说, 开发成本( 按人月计) , 也降不少.

注: 在上述3 / 4 两条, 说到的项目中, 分别是视频业务与金融业务, 我是项目经理/产品经理这一类角色, 除了需求规格说明书( MRD/RSD), 系统总体概要设计说明书( system HLD ) , 子系统概要设计规格说明书( subsystem HLD) , 接口定义文档( ICD ) 以外, 我不写代码.

但是, 如果是 100人月以上的项目, 开发人员在30人以上, 说实话, 这要看开发团队是什么样的人员构成吧. 这涉及到项目的长期维护与更迭换代, 以及人员招聘, 薪水开销等.

所以, 基本还是选择容易招人的开发语言( 与开发语言对应的成熟架框/库). java 挺好招人. go 就不要选择了( 深圳宝安某几个公司, 招 go 开发人员, 招聘信息处处发, 都发了快一年了, 还在四处挂着招人)

几年前, 快递员在小区的手机取件的快递箱, 深圳某大公司以 java 为主, 快递箱内有一台 PC, 通道走2G无线模块, 开箱时间为3秒(2G通道基本通畅的最坏情况). 我在的技术小组作为技术顾问, 作出的优化是, 把服务器端到快递箱内 PC 的通讯, 从原生 java RPC 换成爱立信 ICE 作为中间件的 java RPC , 开箱时间, 缩短到 1.3秒(2G通道基本通畅的最坏情况). ICE 是什么, 爱立信30多年前的 c++ 中间件啊, 20多年来几乎没什么大改进, 性能依然稳定而强悍.

所以, 砖与砖是不同的. c++ /erlang / hackell 挺重, 学习曲线陡上天, java 砖稍重一些, go 砖轻一些, python 轻灵, 而 javascript ( NodeJS ) , 看看 TJ 的经历就知道了.

注1: tj --- koa.js 的核心开发者,当前主力开发语言是 go

注2: nodeJS 2017年前, 用在服务器后端开发, 主要问题是 callback hell, 目前 nodeJs 已经进步很多,并且由于 M$ 主导的 typescript 让 JS 有了强类型支持, VScode 也是"火"了.

1.4 go 在中国很火,是中国程序员们的厚积薄发

注意, 这里我并没有加引号

在中国, 有很棒的程序员, 过去,现在,甚至将来, 很多, 就不一一列示了

为什么 golang 在中国看起来很火?!!!

真正核心的原因是, 中国自1997开始与互联网对接, 到 2007这10年, 中国程序员们, 尤其是在 english 的交流能力普遍"刚好够用"情况下, 依然积累了大量的软件工程实践与思考, 在各自领域里"戴着枷锁跳舞"....

像许世伟, 达达 , smallnest, astaxie, 毛剑....... 等, 把自己在其他编程语言上的积累, 在 go 语言这一新兴现代编程语言下, 各自撸出了一个新世界:

许世伟, 以 go 为基础的七牛云存储, go语言在中国最早最值得尊重的早期布道者
达达, 以 go 为基础的游戏后端,非科班出身的著名游戏公司CTO
smallnest, go 的 rpcx 远程调用中间件
谢大, beego, 很棒很全的web框架,其文档是golang 入门学习到商用的实践经典
毛剑, 以 go 重构后上市的 bilibili

....

还有很多, 很多, 不一一列示

以及, golangchina 中国区 golang 大会, 太棒了......

中国程序员们, 被 golang 解开了"枷锁", 在国际上发出了自己的声音!

赞!

1.5. go 很"火"(假像...), 但绝不是万金油

我想说的意思, go 有特定领域, 有优秀的地方, 但绝不是万金油.

看起来 go 在中国挺火, 这只是个假像.

尤其是 go 还太年轻, 成熟的通用库或架框很少, 很多应用得自己撸. -----> 这个, 看看 uber 就知道了, 自己撸了不少, 还开源了, 例如 uber 开源了自己撸的 zap 日志库, 性能强悍.

相对来说, java 的库与框架, 那是陈年老酒, 好得不得了.

还有 python, python 再优雅再易学, 终究还是那些神级的库让python 开发快人一步, 比如 sqlalchemy, 我的最爱.

事实上 go 在中国或世界范围, 并没有那么火, 但对比 java , go 也并没有那么不堪 .

2 一些建议, 别转到 go 来, 兼修就好

2.1 大可不必从 java /python /nodeJs 转 go

想对刚毕业3年左右的朋友说, 大可不必从 java 转 go

而是应该以 java 为主( 除了视频编解码, 各个研发战场上的主力 ak47 ,通杀) , 同时用 go 作某些部件的效率开发工具( 随身的手术刀, 某些领域一枪见血, 一招制敌) .

如果还有兴趣, python / haskell / sql 也好好玩一把.

对的, 您没看错, 说的就是 sql , 尤其是 plsql 这一类数据库存储过程编程与 NewSQL

精通一门编程语言,再对照其他编程语言, 会对编程/设计这一工具, 有更深入更透彻的理解与实践

2.2 掌握如何编程, 比掌握一门开发语言更重要

这算是卖身说法, "王老"卖瓜吗? ( ........瀑布式开发汗.......)

在 UTstarcom 的 IPTV/OTT 事务部 SA/SE 团队呆过, 8年

历经IPTV解决方案SE/STB 解决方案SE 以及部分业务子系统 SA /播控系统产品线 SE /播控产品线 release SE ( 相当于产品线经理) , 后来拿了 package 出来了

说到开发语言, 个人在商用项目中用过的:

perl ( 搜索 perlchina + tsingson 就知道我的黑历史)
c/c++ ( mobile MSN / MSN中国社区)
PHP, 宇宙第一开发语言, 在某,某,某,某...(都是UTstarcom 的 RollingStream 同一个平台下)用过, 这平台合同标的最大的一个,两个亿吧...
javascript ( 不管是前端还是后端, 都写过一丢丢)
java / java / java ( 企业应用,金融平台, 广电/电信的业务平台RollingStream 的BOSS / 播控产品线/业务导航子系统...,公安交警RFID存储检索平台...)
现在, 当然是, go go go golang + postgres , 一些 Haskell, 一些 Typescript

青春的回忆，向Perl致敬（一） --感谢甄一松

我不知道如何联络上甄一松 , 有知道的朋友, 告诉我一下, 感谢.

中级进阶: 匿名散列表与引用 (tsingson原创) --谢谢路扬 ---------曾经的足迹.... 今晚, 我喝点小酒去

有点感慨, 摘3年前在知乎回复中的一段, 以为记念:

其实，我的英文名 tsingson ，某些中国区老 perler 应该对此英文名有印象，1999年到 2004年，曾经是狂热的 perl 语言爱好者，在中国区大力推广过 perl , 参与过 perlchina 社区前期的一些活动，至今， perl 语言的文化与思想，依然在内心最深层影响着我众多思考方式与职业相关的决策。

离开外企后, 在深圳某机顶盒厂商作过某某运营平台的产品经理( 兼技术总工) 这个某某视频播放平台开发, 以 c++ (mpeg4与.264 .265 推流) / Python (几乎所有业务/运维...) 为主

这个平台的网元划分, 参见文章最后一节, 不算复杂, 终端是电视机顶盒.

这个 OTT 平台很成功( 试商用成功后, 我离开了)

在这个项目过程中, 除了项目启动期3个月, 写过一些业务网元的 prototype 作为演示外, 我几乎没写过在商用部署中的代码( 应该,不超过 1000行), 时间宽泛,我就花了两个月自学了 go, 先是写了一些命令行小工具,再写了一些tcp/udp 的小工具, 流式传输大文件, 测试网络抖动/网速采集....

3年后, 因为该某某平台很成功, 我也就山寨了自己一把,全新设计, 重写代码, 用 go 重新实现并商用成功(当然, 商用还在进行中) .

我想说的是, 这个平台, 除了一些"小差别", 用 java 也差不多

问题是

我空降去当产品经理时,给我7条枪,除了两个c/c++ 老手, 10k以上, 其余成员, 工作3年上下, 初级研发, 各种开发技能都不深入, 基本没学过python (一个月后, 从其他部门收了一个 python 开发熟手), 当时平均薪水是8K...

5个月后, 平台开发几轮后开始规划试商用上线前后, 我招了 3个 15K+ 的好手, 几个实习生(文档/测试/web界面一发...)

这个平台的网元划分, 参见文章最后一节, 第一个试商用版本上线,开发了6个月

虽然作为产品经理, 我有部分人事权/财务权,事实上为此在公司内引了不少争议(主要是公司平均资酬比较低,我招聘的开发好手, 开出的薪资都与常务副总一样了...)

2.3 小差别? 是哪些小差别让我选择 go 作为现在的主力开发语言

小差别, 真的看起来很小:

部署, 编译可执行文件, 加个配置文件说明文档, 接口验证服务健康运行的接口文档,一起打个包, 就丢给运维 copy 后运行, 好了,结束.
写代码, 编译, 测试( UT/LIT/SIT...), 关闭开发测试日志, 编译, 丢给运维, 好了, 结束
运维报告说, 有用户连接不到服务, 查用户在线数量, 超5000 ( 这是内部限制值), 让运维开新服务器, 再 copy 一份运行, 好了, 以后同此办理, 别来烦我.... 运维说, OK, 你旅行去吧...

除了 c/c++ , 其他语言有这么轻松的进行部署吗? 当然有...

但是

我们的运维几个,很年轻(21岁上下), 管理几百台服务器,几十个网元服务, IDC机房在北美,新加坡,欧洲..., 小运维还在上学

2.4 小结一下

编程, 就是设计

软件工程上的设计就是解决问题, 精通一门编程语言(无论是什么,做到真正的精通),做一个"问题终结者"

做一个"问题终结者", 这是个人价值所在(挣点小钱), 这也是欢乐的源泉(空出个人时间, 与家人好友, 美食/旅行/摄影/音乐/绘画/写书....享受生活的快乐)

各位爷, 看看在街头的我, 给您咧位吹上一曲, 放松一下

3. 一些有趣的补充

3.1 补1 , 一些开发文档的名称编写

有知友问到那几个英文缩写. 简单说一下, 英文缩写只是某些习惯用词罢了.

需求规格说明书( MRD/RSD)

就是作需求分析写的文档, MRD 中指的是 marketing Requirement Documention 即是市场需求, 是写给甲方与售前的, 目标是确认需求细节. 一般来说, 大公司技术投标附带的那个技术需求细节说明文档, 可视为 MRD.

RSD 是 Requirement Specification Documention , 说白了就是 use case 的集合, 是写给开发人员与测试人员看的

系统总体概要设计说明书( HLD )

细一点, 分为 system HLD / sub-system HLD. HLD是 High Level Design Documention , 俗称系统架构/概要设计吧, 说简单一点就是划分子系统, 确定各子系统之间的分工界定, 子系统概要设计规格说明书( subsystem HLD) , 就是个类似的玩意儿.

当然了, 有HLD 概要设计, 对应就有详细开发设计文档, 不展开了

嚯哈, 文章最后有一小图, 可以瞅瞅

接口定义文档( ICD )

英文是 Interface Control Document , 直译英文就是接口控制文档, 这个是老生常谈了, 开发与测试中依赖最多的文档. 例如定义 web 服务器与 web 浏览器之间的 http 1.1 接口文档, RFC 7230 ~ 7235 , 当然了, 这类文档, 也可以叫 protocol specification 某某协议规范说明文档

3.2 补2, 软件架构, 什么东西

注: 这部分是给刚开始考虑软件架构, 以及了解架构师这一角色的朋友写的, 很不严谨, 如有不适当的地方, 恳请指点批评, 先谢谢了.

有朋友问什么是软件架构, 架构师是作什么的? ( 甚至有朋友问, 曾经作为架构师/产品经理/技术总负责的你, 为什么可以不写代码) ?

是的, 我曾说过, 我作为架构师, 在工作中, 基本不写代码

(事实上也写过一些代码, 比如写验证解决思路或算法的 prototype 原型, 或一些应急使用的补丁或工具, 这些代码一般不会长期用在生产环境中)

不写代码的架构师, 不表示不懂写代码, 哈, 这就不引战了.

architecture 架构 , 这是个简单又复杂的玩意儿, 这里就简单说说, 帮助了解

3.2.1 程序设计, 是这样, 大约

这里先说一个简单的业务(multi-user todo-list)

用户在一个网站上用手机号注册/登录( 鉴权/授权)

登录成功后, 在网站的web界面中, 给自己发延时( 在将来的一周内任意时间点上定点) 提醒的文本信息, 发到自己的手机短信上.

web界面可编辑发布的时间(当前时间开始, 将来的一周内任意时间点), 可编辑要发送的文本( 500汉字以内)

每人等待发布的信息总量是 100条, 发送短信信息的送达时间点误差允许在2分钟内变动. 短信发布后, 从用户的等待发布列表中移到历史记录中, 并记录短信发布状态供web 界面历史查询即可.每个人的延时信息发布提供历史查询上限为1000条, 超过1000条的, 按时间排序删除旧信息.

每个用户只能查看自己的信息, 无法查看他人信息.

用户使用这个 todo-list 全免费.

好, 上面就是业务需求了, 当然, 也基本描述了业务流程和一些规格要求.

隐藏着的一个需求是, 要和电信服务商对接, 以提供手机短信发送服务. 这里, 我们简化为中国电信已经提供无限量的免费接口, 中国各省市县并发无限量同时短信送达时间为 1 秒 , 对接方式也是简单有保障. 哈哈, 普大喜奔吧.......

( 这里简化掉了资费问题, 也简化掉了部署/运维/运营成本.......等问题)

上面的业务, 其实任何一个开发人员都可以实现.

不管如何设计, 如何实现, 基本都会达成目标. ---------------------------> 这个, 就叫程序设计了,

但不太合适叫架构设计.

3.2.2 架构设计

达成 1 ~ 6 条目标, 一般不称之为架构设计, 一台服务器就搞定

那什么情况下叫架构设计??

在实现上面业务功能基础上, 加上实现一下保障业务长期/大量的全流程实现要求, 就叫架构设计了:

multi-user todo-list 业务要求支持并发1千万用同一秒发送1千万条信息, 短信送达时间延迟, 排除电信传输时间, 不得超过3分名, 至少持续15天不间断服务(类似淘宝黄金周), 支持用户总量1个亿,活跃用户4千万, 支持用户范围为中国境内所有中国电信手机覆盖的省市县乡.

multi-user todo-list 业务要求单个用户登录 / 操作自己的延时短信提醒的 web页面在 IE11 以上的同等浏览器中, 页面响应时间为200ms, (去除去网络往返响应时间后200ms, 允许上下20%波动), 最慢响应时间不超过 1800ms ( 接近最慢响应影响用户, 不得超过并发用户总量的 5%)

要求整个平台每年全平台完全中断服务时间累计底于30分钟, 按县市级行政区划分, 每个行政区年累计中断业务时间累计, 不得超过6小时.同时, 按县级行政区总量计,同一时间段内, 中断业务的县级地区, 不得超过总量的10%

要实现 1 ~ 9 需求(重点就是 7/8两条) , 需要架构设计的帮助.

而架构师, 解决的就是7/8/9三点, 在解决7/8/9 的基础上, 会对 1-6 的实现, 有很大的干预.

当然了, 附带的, 架构师在技术选型与整体设计中, 除了技术成熟度, 商用支持, 学习曲线, 经验积累与人才储备, 也会考虑开发团队的成本, 开发效率, 运维的成本与效率, 运营成本, 部署成本, 人员变更(包括外包) , 技术升级, 业务功能可扩展性, 与第三方对接的成本/效益.........

想清楚了 7/8/9 这类架构师面对的问题, uber 从 postgres 转到 mysql 的动因也就清楚了, 并不是 postgres 不优秀, 而是 mysql ( 真实原因是 mysql 的那个低层存储引擎) 更适合 uber 的超大存储/查询需要. 对于架构师来说, 单一部件的优秀, 开发高效或执行高效, 并不是唯一决定架构技术选型的因素.

4. 后记

附图一张, 2015年画的, 2.2章节提到的某某某平台, 给新人了解这个某某某平台的第一张图, 网元之间的分工界面:

. 致敬 golang 的缔造者:

Go语言的三位最初的缔造者 — Rob Pike、Robert Griesemer 和 Ken Thompson 中，Robert Griesemer 参与设计了Java的HotSpot虚拟机和Chrome浏览器的JavaScript V8引擎，Rob Pike 在大名鼎鼎的bell lab侵淫多年，参与了Plan9操作系统、C编译器以及多种语言编译器的设计和实现，Ken Thompson 更是图灵奖得主、Unix之父、C语言之父。这三人在计算机史上可是元老级别的人物，特别是 Ken Thompson ，是一手缔造了Unix和C语言计算机领域的上古大神，所以Go语言的设计哲学有着深深的Unix烙印：简单、模块化、正交、组合、pipe、功能短小且聚焦等；而令许多开发者青睐于Go的简洁、高效编程模式的原因，也正在于此。

------------ 摘自blog.taohuawu.club/article/gor… 作者: 潘建锋, 谢谢!

终于写到最后了, 放上我尊敬的一位说真话的程序员/设计师:

王垠--编程的智慧

能看到这里, 谢谢了, 小文有点啰嗦.

浪费您时间了.

以上,致敬, 祝愉快.