共计 1574 个字符，预计需要花费 4 分钟才能阅读完成。
接触 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。各有各有优势的地方。在工作中依然会大量使用这两种语言。这里只是表达下自己工作中的感受，为后来者选择做个参考。
