用 Go 写 Web 后端合适吗？

很多人搞错一点，业务复杂度不等于解决方案的复杂度。互联网大厂的某些项目可能业务不是很复杂，但是因为高负债、高并发等非功能需求导致解决方案实现复杂，这种项目可能 go 是比较合适的。但是如果业务逻辑本身的复杂度很高的项目，可能 go 就不如 c#、java 合适了

go 写业务最大的问题其实还是生态环境不够完善吧，比如之前要搞工作流引擎，最后发现 go 这边没有成熟的方案，而 java 有 Activiti 啥的，就连 bpmn 在 go 这边也只有很原始刚开始做的库，那没办法，就只能自己造轮子了

那 go 主要用来干嘛？？

@Ufo666 造中间件轮子升职加薪。

@NaVient 微服务噢。
比如说我司，一个 CRUD 业务，基本上可以说就是 1-3 个写入接口这种业务复杂度吧。
后端拆成 10 个左右的项目，有负责热数据的，冷数据的，proxy ，统计，等等。
这样每个项目复杂度就下来了，用 go 就合适。
但是我司基础设施牛逼啊，切流，身份验证，负载均衡，文件系统什么的 都是现成的。

如果你都写在一起，就不好玩了。

@lionel0806 这是业务系统？

go 写业务系统纯粹是给自己添堵，go 的设计目标是开发一些基础组件的

在新业务没有历史包袱、并且能够实现人力招聘的前提下，大厂都在拥抱 go ，只剩下半桶水程序员还在吵吵不适合

很多人怕是不知道某些大厂内部的 java 基础设施有多么让人作呕。
没错，我说的就是阿里之流

@pastor

找个基础设施比阿里好的出来？

@pastor 没用 go 写过业务代码还真信了你了

@NaVient #70 有没有可能人家内部已经造了很多轮子

@javaisthebest 丰富完善能罩得住业务，但是太丑陋了，让人作呕是因为太丑不是它不丰富不完善。另外，好多阿里同学自己吐槽他们内部框架臃肿不堪、性能低下。
我不知道兄弟你是不是阿里的或者是哪个部门的，或许你见过的阿里的东西比较好？能否推荐个我去学习下，免得我也被各种阿里同学或者非阿里同学整天骂阿里的 KPI 开源误导了（不过我看过一些阿里的开源，确实挺让人作呕的）。就是因为听说了这么多，所以阿里的哥们想内推挖我都直接拒绝了，审美取向不合。。。

@redvoilin 很多团队还真没怎么用对 go 。尤其历史包袱重的团队，或者比如 php java 转 go 的同学，我并不是鄙视 phper javaer ，而是因为以前积累的基本功造成的技术栈审美取向与 go 确实有较大不同，所以就像很多人喷 go 一样，gopher 也喷绝大多数其他语言的解决方案

上份工作是用 gin 写过 web ，感觉生态还不是很全，业务逻辑复杂的时候，要自己写的逻辑比较多，比较累，但是运行速度效率这方面没什么问题。

看下来还是 java 一桶天下啊，都是框架了

路过，还是想问下说业务复杂的各位，
除工作流之外，正心请教还有哪些属于各位说的复杂的业务？

当然，若是没用微服务来拆，一把梭哈做个复杂的单体应用——这样的情况不用回答，我承认是非常复杂

另外，对于某些说 go 的基础设施不齐全之类（如限流、监控、负载均衡、调用链等），
真心建议去了解下 k8s ，还有服务网格

@lizuoqiang 不可能，基本都是需要一套脚手架+代码生成工具+ bla bla bla ，纯 CRUD 自己要做的事情可少了。可能不比成熟的语言快，例如 php 、python 、java ，但是开发效率肯定不慢....

我们组的后端基本是 go ，比 python 好维护太多了，比 java 代码少且好读

不用太担心泛型不够用、重复的代码、性能不够、生态，uber 和字节都大规模的使用，反正造轮子、看第三方包源码都很方便。

现在基本不用自己造轮子了，先看看这里 https://github.com/avelino/awesome-go

我最喜欢的，松散的 package/struct method 等设计，重构代码、组合代码、测试代码都太方便了，几乎是一行流、一键完成，修改调整文件名都不需要重构代码本身