接触 go 至少 5 年了。一直关注 go 的发展,期间也用 go 做过不少工具,最近一年引入了生产用来开发业务系统。简单的 api 项目非常简单轻量,但是需要手动处理的东西也很多。
生产中使用的是 gin 框架,依赖注入使用 wire ,也编写了很多工具类,该有的都有了。处理复杂场景时依然显得力不从心,也有很多令人疑惑的地方。在 java 中通过一个注解来切面,就可以实现关键接口日志的记录。比如 @Log("删除管理员")。而在 go 中就麻烦很多,需要为每个接口添加中间件,想获取后面执行方法的参数和返回值也相当困难。我们记录日志,也不可能只能记一句话,还需要操作人信息和操作参数及结果。
编译速度没有想象的快,很多时候改动文件多了后,要半天,当然没有改动,第二次启动就快的多了(我们用的 goland )。
二进制启动快,这是优点,但是好像并没有带来什么收益,只是从一个开发人员角度来看,启动很快,很爽,对业务并没有带来什么收益。因为发布的流程是很复杂的,并不是扔上去就直接给用户用,相比较验收等流程来说,1 秒和 10 秒 50 秒几乎忽略不计。
二进制包下,这也是优点,2 阶段构建,我们使用 docker 镜像可以达到整体就 20m 左右,而同样的 springboot 达到 130m 左右(进一步模块化可以达到 80 左右)。但是服务器和制品库之间都是内网,几乎没有感受到明显差别,只对第一次拉取镜像有点用,后续镜像层拉过的都不会重复拉取。
内存占用 go 真的很低,20m 左右,springboot 启动就要给 512 避免内存溢出,当前 128 甚至 64 也可以启动,但是就不能用了。我们的业务服务器都是 2 核 4G ,感觉 go 有点浪费的感觉。
大内存,这点 go 做的不好,固定频率的 GC 在大内存占用时停顿明显。毛刺明显,而不像 java 可以根据业务选择合适的垃圾收集器,调优下很平滑。go 甚至没有提供可以选择的参数。
编程体验,都说 go 好,但是我不这么认为,对于工具类,简单 api 项目,go 确实很好。简单。不需要任何复杂的依赖。但是对于有一定复杂度的项目,感觉 go 的内置库相当匮乏。比如在 java 中可以使用 stream 等一套下来就是最终的数据。而在 go 中即使借助外部库,也需要多步才能完成(别跟我说自己写一个,你去写)。
另外就是 error 问题,写的时候一步一处理。很稳健。但是也很烦。过几天回来看代码,只能看到满屏的 if err != nil 。正常的业务逻辑已经湮没在 error 的海洋里。又臭又长(等等,这个不是说的 java ?)
类型推断,声明变量时不用写类型。有好处也有坏处,好处是少巧几个字母,坏处也显而易见。比如,某个 controller 层调用 service 层代码。user := us.GetUser(ctx, uid),此时如果我想看下返回的数据结构必须到 service 层看,这层是看不到的,也点不进去,像 java UserResp user = us.GetUser(uid),直接点击 UserResp 就能快速到定义。而 go 层次一多就很烦,需要一层层,一层层到最后返回值的地方才能看到。
依然有空指针,nil pointer 。特别是解引用时遇到最多。比如*user.name
半吊子泛型,虽然 java 的泛型实现的也不怎样,但是作为程序员是不关心字节码层面和机器码层面如何实现的,只关心有无,好不好用。
生态,go 的生态云原生基础设施比较多(不是说云原生就是 go ,云原生概念反而是 spring 后面的公司提出来的),业务相关的比较少。而 java 就很多了,很多基金会的组件也很优秀,多如牛毛,java 不仅仅是一门语言,现在说 java 基本是说其对应的生态,包括 kotlin ,java 等等,选择太多甚至出现选择困难症。
说这些不是踩 go ,也不是吹捧 java 。各有各有优势的地方。在工作中依然会大量使用这两种语言。这里只是表达下自己工作中的感受,为后来者选择做个参考。