当年 写 CGI , php 打败了 perl , 无他, 在 web 的 CGI 时代, php 学习成本低.
同样 , 2018年 vueJS 与 react 相比更为"火", 无他, vuejs 学习成本低.
go 相对于 java 也有点类似, 学习成本低.
好几年前, 游戏开发, erlang 在后台来说, 那是中坚力量, 而这两年, go 作为游戏开发的后台, 也不少了吧.
也一样, 相对 erlang , golang 学习成本 低.
有答主说了 "其实有多大差别啊,搬砖而已" ---------> 我同意这句话, 但也不完全同意这句话
同意的地方是, 对于传统业务, 尤其是企业级应用或业务, 以及有明确终端用户的业务来说, 在不考虑量级情况下, 业务实现流程与管理约束有相似之处, 开发实现也有相类似之处.
所以, 不同语言/架构开发来说, 差别不明显, 比如说, 用户管理 / 资费交割/ 业务鉴权 / 商品管理都差不太多( 这里没说内容管理, 内容差别太大, 但商品管理差别不会大) .
这里说的业务量级, 指的是用户总量, 并发量, 业务运行随时间累积的数据总量与有效数据集总量
比如大型网店, 下架后的商品数据, 对于网店销售来说, 属于失效数据集, 但对于销售行为分析等大数据估算来说, 是有效数据集)
对于这些, 不同语言开发, 就是搬砖.
那搬砖有什么不同呢, 无他, 人不同罢了:
有朋友说了, "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 也是"火"了.
注意, 这里我并没有加引号
在中国, 有很棒的程序员, 过去,现在,甚至将来, 很多, 就不一一列示了
为什么 golang 在中国看起来很火?!!!
真正核心的原因是, 中国自1997开始与互联网对接, 到 2007这10年, 中国程序员们, 尤其是在 english 的交流能力普遍"刚好够用"情况下, 依然积累了大量的软件工程实践与思考, 在各自领域里"戴着枷锁跳舞"....
像 许世伟, 达达 , smallnest, astaxie, 毛剑....... 等, 把自己在其他编程语言上的积累, 在 go 语言这一新兴现代编程语言下, 各自撸出了一个新世界:
....
....
还有很多, 很多, 不一一列示
以及, golangchina 中国区 golang 大会, 太棒了......
中国程序员们, 被 golang 解开了"枷锁", 在国际上发出了自己的声音!
赞!
_
赞!
_
赞!
_
我想说的意思, go 有特定领域, 有优秀的地方, 但绝不是万金油.
看起来 go 在中国挺火, 这只是个假像.
尤其是 go 还太年轻, 成熟的通用库或架框很少, 很多应用得自己撸. -----> 这个, 看看 uber 就知道了, 自己撸了不少, 还开源了, 例如 uber 开源了自己撸的 zap 日志库, 性能强悍.
相对来说, java 的库与框架, 那是陈年老酒, 好得不得了.
还有 python, python 再优雅再易学, 终究还是那些神级的库让python 开发快人一步, 比如 sqlalchemy, 我的最爱.
事实上 go 在中国或世界范围, 并没有那么火, 但对比 java , go 也并没有那么不堪 .
想对刚毕业3年左右的朋友说, 大可不必从 java 转 go
而是应该以 java 为主( 除了视频编解码, 各个研发战场上的主力 ak47 ,通杀) , 同时用 go 作某些部件的效率开发工具( 随身的手术刀, 某些领域一枪见血, 一招制敌) .
如果还有兴趣, python / haskell / sql 也好好玩一把.
对的, 您没看错, 说的就是 sql , 尤其是 plsql 这一类数据库存储过程编程与 NewSQL
精通一门编程语言,再对照其他编程语言, 会对编程/设计这一工具, 有更深入更透彻的理解与实践
这算是卖身说法, "王老"卖瓜吗? ( ........瀑布式开发汗.......)
在 UTstarcom 的 IPTV/OTT 事务部 SA/SE 团队呆过, 8年
历经IPTV解决方案SE/STB 解决方案SE 以及部分业务子系统 SA /播控系统产品线 SE /播控产品线 release SE ( 相当于产品线经理) , 后来拿了 package 出来了
说到开发语言, 个人在商用项目中用过的:
青春的回忆,向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个月
虽然作为产品经理, 我有部分人事权/财务权,事实上为此在公司内引了不少争议(主要是公司平均资酬比较低,我招聘的开发好手, 开出的薪资都与常务副总一样了...)
小差别, 真的看起来很小:
除了 c/c++ , 其他语言有这么轻松的进行部署吗? 当然有...
但是
我们的运维几个,很年轻(21岁上下), 管理几百台服务器,几十个网元服务, IDC机房在北美,新加坡,欧洲..., 小运维还在上学
编程, 就是设计
软件工程上的设计就是解决问题, 精通一门编程语言(无论是什么,做到真正的精通),做一个"问题终结者"
做一个"问题终结者", 这是个人价值所在(挣点小钱), 这也是欢乐的源泉(空出个人时间, 与家人好友, 美食/旅行/摄影/音乐/绘画/写书....享受生活的快乐)
各位爷, 看看在街头的我, 给您咧位吹上一曲, 放松一下
有知友问到那几个英文缩写. 简单说一下, 英文缩写只是某些习惯用词罢了.
需求规格说明书( 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 某某协议规范说明文档
注: 这部分是给刚开始考虑软件架构, 以及了解架构师这一角色的朋友写的, 很不严谨, 如有不适当的地方, 恳请指点批评, 先谢谢了.
有朋友问什么是软件架构, 架构师是作什么的? ( 甚至有朋友问, 曾经作为架构师/产品经理/技术总负责的你, 为什么可以不写代码) ?
是的, 我曾说过, 我作为架构师, 在工作中, 基本不写代码
(事实上也写过一些代码, 比如写验证解决思路或算法的 prototype 原型, 或一些应急使用的补丁或工具, 这些代码一般不会长期用在生产环境中)
不写代码的架构师, 不表示不懂写代码, 哈, 这就不引战了.
architecture 架构 , 这是个简单又复杂的玩意儿, 这里就简单说说, 帮助了解
这里先说一个简单的业务(multi-user todo-list)
用户在一个网站上用手机号注册/登录( 鉴权/授权)
登录成功后, 在网站的web界面中, 给自己发延时( 在将来的一周内任意时间点上定点) 提醒的文本信息, 发到自己的手机短信上.
web界面可编辑发布的时间(当前时间开始, 将来的一周内任意时间点), 可编辑要发送的文本( 500汉字以内)
每人等待发布的信息总量是 100条, 发送短信信息的送达时间点误差允许在2分钟内变动. 短信发布后, 从用户的等待发布列表中移到历史记录中, 并记录短信发布状态供web 界面历史查询即可.每个人的延时信息发布提供历史查询上限为1000条, 超过1000条的, 按时间排序删除旧信息.
每个用户只能查看自己的信息, 无法查看他人信息.
用户使用这个 todo-list 全免费.
好, 上面就是业务需求了, 当然, 也基本描述了业务流程和一些规格要求.
隐藏着的一个需求是, 要和电信服务商对接, 以提供手机短信发送服务. 这里, 我们简化为中国电信已经提供无限量的免费接口, 中国各省市县并发无限量同时短信送达时间为 1 秒 , 对接方式也是简单有保障. 哈哈, 普大喜奔吧.......
( 这里简化掉了资费问题, 也简化掉了部署/运维/运营成本.......等问题)
上面的业务, 其实任何一个开发人员都可以实现.
不管如何设计, 如何实现, 基本都会达成目标.
---------------------------> 这个, 就叫程序设计了,
但不太合适叫架构设计.
达成 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 的超大存储/查询需要. 对于架构师来说, 单一部件的优秀, 开发高效或执行高效, 并不是唯一决定架构技术选型的因素.
附图一张, 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的简洁、高效编程模式的原因,也正在于此。