这是一个创建于 96 天前的主题，其中的信息可能已经有所发展或是发生改变。
接触 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 。各有各有优势的地方。在工作中依然会大量使用这两种语言。这里只是表达下自己工作中的感受，为后来者选择做个参考。
130 条回复 • 2024-07-13 14:56:10 +08:00
 |
101
sophos 95 天前  1
我这边 go 和 java 都有大量服务在线上跑着，以下数据比较粗略，只是做个大概的对比
开发 go 服务的机器 cpu 平均利用率不到 30%，开发 java 服务的机器 cpu 平均利用率超过 60%，构建时能到 90%+ 打包构建时间，go 一般是 20s 左右，java 大概要个好几分钟吧 同样的 k8s 滚动发布 10 个 pod 的服务，同样的 RollingUpdate 策略，go 服务大概需要 20s ，java 服务大概需要 10 分钟 线上运行的容器内存占用，go 一般是 100M 左右，java 一般超过 2G |
 |
102
cruii 95 天前
不要用 java 的视角来看 go
err 是看着难看，但 java 的异常并没有好到哪里去，大多数不都也是直接 throw ，然后异常处理器。针对不同的异常，不也是需要分别处理。这都是理想情况，能有多少是把不同类型异常分开处理呢。见过很多都是抽象一个 AbstractException ，业务异常继承，然后直接所有业务异常都是走这个 handler 。 这也不美啊。 |
 |
103
coderzhangsan 95 天前
@beneo 研发成本有 2 大开支，首先是研发人员人力成本，其次才是服务器成本，无论 go 还是 java 都是有钱才能玩的，没钱只能 php 一把梭了。
|
 |
104
tt67wq 95 天前
web crud 的场景用 go 不是找不自在吗？
|
 |
105
SurfaceView 95 天前
你在这个地方问 java ，肯定是要被喷的， 这是 zzzq
|
 |
106
thoo61871 95 天前
当年买过本 java 的书，他妈的比新华字典还厚，果断放弃了写 python 和 go 去了，go 写久了，python 都不想碰了。
|
 |
107
wupher 95 天前
以下仅为个人选择：
- 纯 web service 还是更喜欢用 Java / Kotlin / Spring ，甚至架构足够简单，node 也行。 - Go Service 一般还是用于实现诸如 Sockets 类通信。 |
 |
108
0xsui 95 天前
@coderzhangsan 用 laravel 做各种事情~
|
 |
110
xiangbohua 95 天前
我觉得“满屏的 if ！= ni”的判断有点奇怪，难道不能用异常捕获机制嘛？不了解 go
|
|
111
xiangbohua 95 天前
@NewYear 我们公司配的 jinkins 发布，弄个注册中心，就两台机器，先注册中心下线、等一会缓存清空，在重启第一台，第一台启动经过漫长的启动之后轮训检查一下服务起来没有，再重复上面的过程搞第二台。
就为了两台机器的平滑启动，发布一次 jinkins 至少等 10 分钟。 哎 |
 |
112
sulinehk 95 天前
感觉说的还是挺中肯的。
|
 |
113
lysShub 95 天前
`user := us.GetUser(ctx, uid),此时如果我想看下返回的数据结构必须到 service 层看`
goland 不清楚，gopls 支持直接转到类型定义 |
 |
114
privil 95 天前
@xiangbohua #111 生命苦短，需用 golang 哈哈哈
|
 |
116
number201724 95 天前
差不多 4 年前准备把 MFC 写的服务换成 go 然后用 go 写了一些逻辑，上了一个压力测试发现查询成功但是返回 ErrBadConn
调了一周发现是 go 语言自带的 sql 库有问题…… 具体表现是：数据库连接池超过 50 个连接，然后并发压力测试打满 50 个以上就会 ErrBadConn……问题是查询成功了，然后返回的是 ErrBadConn....从此没用过 go 了 https://github.com/golang/go/blob/46cb016190389b7e37b21f04e5343a628ca1f662/src/database/sql/sql.go#L664 |
|
117
coderzhangsan 95 天前
@SurfaceView php 表示这算什么，在下已经被喷了很多年，直到我没落，还有人不忘踩 2 脚🤣🤣🤣
|
 |
118
DesnLee 95 天前
@grittiness 试试 sqlc
|
 |
120
hancai2 95 天前
客户让搞个 demo 环境，跑起来看看。 我们这项目跑 demo 要 128G 内存，客户说那还是算了吧。
|
 |
121
lvlongxiang199 95 天前
写业务感觉还是 java, ts 最方便. go 擅长写重网络 IO 的应用, 用同步的方式写异步比较舒服
|
 |
122
grittiness 95 天前
@lolizeppelin ent 在多表复杂关联的情况下是不是不太好用？以前有了解过，印象中简单 crud 好用，复杂关联好像写起来很麻烦
@DesnLee sqlc 是不是更简陋？分页之类的有写好的轮子了吗？ @dododada 手搓写起来太麻烦了，基础的分页、权限控制之类的，写起来也很费时间还觉得麻烦 |
 |
123
lambdaq 95 天前
@number201724 感觉超过 50 个也挺危险的。。
|
 |
124
GeekGao 95 天前
如果不考虑后期性能优化相关的成本投入，我觉得还是 python 提升得开发效率更多一些。
|
 |
126
cmsyh29 95 天前
@itskingname 然而生产都要求 go 单测覆盖率 写到吐
|
 |
127
lesismal 94 天前 1
> 大内存，这点 go 做的不好，固定频率的 GC 在大内存占用时停顿明显。毛刺明显
go 的 gc 已经很丝滑了, 多数人的业务量也不会有瓶颈. 我这里的百万连接的对象 map 优化下确实省不少: https://github.com/lesismal/nbio/pull/304#issuecomment-1583880587 其他很多场景也可以定制数据结构针对性优化 gc 至于调 gc 参数, 对于一些常驻对象数量大的, 仍然不太好解决根本问题 |
 |
128
wyds591101 94 天前
我觉得还是看做什么吧，Go 有很多优点，但是我写业务逻辑的时候，我还是觉得 java 快一些。GO 我做项目参考的 gin-vue admin 。
|
 |
129
wxl2578 94 天前
我不信你有 5 年的 go 经验
|
 |
130
gvison 77 天前
在简单的 restful api 、工具、更复杂的微服务项目方面，个人感觉用 go 还是可以兼顾到节省资源和开发效率的，开发效率方面用到了开发框架 sponge ，在项目层级上自动生成和合并代码，减少了大量原本需要手写的代码，只需编写业务逻辑代码。
|
Select Language