求从 Python 转 Go 的实际经验分享

顺手再贴个 老招聘贴（ Python & Golang ） https://www.v2ex.com/t/333691

话题太大

转呗。 不考虑轮子，开发效率差不多的。但性能可好多了。

我转了之后都是优先用 go， 有个别的为了用轮子用的 python。

反正在微服务架构下语言随便用。

最大的问题是前两天在 python 里写出来个大括号，检查了 10 分钟硬是没想通为啥语法错误。

正在考虑转，Mark 一个

有什么场景需要转 go ？区块链开发？

原因：看好 go 的发展，原来两年多的 python 代码，业务逻辑面目全非了。
效率：
15 年早期两个人一个多月使用 clojure 初始化项目 1.5m x 2p
15 年末 clojure 不好招人，一个人用 python 花了一个多月时间重写 clojure 的项目，开始招 python 工程师。1.5m x 1p
17 年中两个人用了两个月时间用 go 重写了 python 的项目 2m x 2p

我个人看来，开发效率方面差不多。go 花的时间更长，一方面业务更复杂，另一方面还要造些轮子。

坑？不记得了，该填的都填了，填不了的都将就了。
收益？换静态语言后，感觉编译过了事情就完成一大半了。

楼主，你得先说你做什么领域

饿了吗不是在转 java 吗？
用 go 重构 python 代码一般来说资源消耗大概能降低到原来的 1/5 到 1/10，并且延迟大大降低，开发效率熟悉之后其实相差不了多少

以前写爬虫用 python，后来开始试着用 go，刚开始各种不顺手，各种理由回到 python，用久了 go 也一样写，并不比 python 麻烦，而且很大一个好处是不用配置运行环境，可以交叉编译，想放到哪里跑，直接编译二进制文件扔过去就跑

我以前在一家做图像分类的公司完整经历过 Python 转 Go。
最开始我们的业务架构是 all Python，api 服务使用 flask + celery + redis + mongdb + 基于 thrift 的 C++服务， 处理简单的图片分类。
转的原因：后面来了一个业务需求，对 api 的响应速度和 qps 都有要求，基本上是几千 qps 每秒。因为本身的业务逻辑比较简单，所以我们 profiling 了下，发现瓶颈在 Python 本身。我以前用过 Golang，所以基于 Gin 框架实现了一个简单的业务逻辑进行压测，发现性能比 Python 好很多，达到我们的预期。

## 工程效率对比：
* 一个是响应时间快了不少，Python 的话能优化的空间有限，而且效果也不是很理想
* 单机支持的 qps 提升很多，不需要增加线上的机器就可以满足新需求
上面这两个提升基本是 5 倍左右吧，具体记不清了

然后我们基于 Golang 实现了原来的鉴别服务，达成了项目需要。

## 遇到的坑：

* 包生态还不完善。我们重度依赖 Celery，Golang 当时没有类似 Python Celery 这个库，所以只能参考 Celery 的原理实现一个类似的。还有一些基于 Pandas 的代码还是保留 Python 版本。
* Golang 的包版本管理以及下载比较麻烦，本地有代理还好，线上部署如果是实时拉代码的话很麻烦。后来我们把需要的库都本地打包到 docker 镜像里作为 base image。

## 其他收益

相比 Python 好的地方
* Golang 的类型检查和基于防御性编程的错误处理方式，减少了很多 Bug 发生率，不像 Python，有时候一个错误会传递很深
* Golang 的 goroutine 加 channel 在实现一些跟并发相关的控制逻辑时非常简洁
* 对重构友好，完善的语法补全、定义跳转。我们的 Golang 项目都是用 vim 写的，基于 vim-go 插件，基本可以达到跟 ide 一样的效果，用 Python 的话基本不敢想象比较大的项目离开了 Pycharm 后面会变成怎么样
* 编译速度快，支持跨平台编译，部署方便，内存占用低，长时间运行非常稳定
* 自带 profiling 工具，性能分析方便

跟 Python 比不足的地方
* Golang 开发效率的降低，主要是内置库没有 Python 丰富加上需要类型的缘故，会稍微繁琐一点。目测开发相同功能应该是降低到原来的 1/2 或者 1/3。但是如果算上 Golang 带来的 Bug 提早发现减少的后续开发维护工作的话，我感觉并没降低太多。毕竟修 Bug 是个很蛋疼的事情，尤其是 Python 这种
* 测试麻烦。Python 有 mock，写测试还是比较舒服的。但是 Golang 的话，如果没有一开始就基于 interface 去思考这个代码怎么测试的话，后续写测试很蛋疼

零零碎碎就记得这些了，可能有些随着时间流逝外加 Golang 生态圈的变化已经失效了，列在这里仅供楼主参考

Ruby 也想转 go 了，工作机会多不少

漏了一条，自带 go fmt，省心省力，再也不用纠结代码格式的问题了

感觉没有什么转不转的， 语言就是工具而已， 学会一个就多会一个.

我在公司实际 python 和 go 都会使用， 主要还是看项目用什么合适，

给我个人最大的感受就是，go 的性能还是有明显的优势， 编译成一个二进制文件也很方便，另一个就是异常处理， 我觉得 go 的处理方式比 python 好， 其他就是一些什么库啊什么的， 其他人肯定会补充的。

我们一开始用 python 只是觉得 python 对 windows 下开发友好而已，后来发现很多功能 windows 下也是不完整的。go 我觉得目前算是跨平台最友好的语言了

之前写 Python，最近一个项目在用 golang
先说优点
1. 性能比 Python 好挺多，基本上写出来就能有不错的的性能
2. Goroutine 和 channel 很好用，
3. 默认静态链接，部署方便
4. 静态类型，重构比 Python 安全很多
5. gofmt 减少了很多关于代码风格的争论
缺点：
1. 表达力有点弱：动态语言在特定的问题领域可以写出很抽象的代码，实现很高的代码复用度，golang 在这方面就差了不少；没有泛型，很多时候只能靠运行时做 type cast 或者 type assertion 来解决
2. 未使用的变量 / import 会导致编译错误，这点对调试非常不友好，有时候为了注释掉一行代码要改好几个地方
2. 没有一个好用的包管理，使用过的里面感觉就 govendor 还能用，官方的 dep 还不成熟
3. 没有好用的 ORM：没有像 SQLAlchemy 一样强大的 ORM （这其实算是 1 的结果）
4. 标准库里的 errors 包没有 stacktrace （可以用 https://github.com/pkg/errors 来弥补）
5. 一些奇怪的规则，比如 internal 包不能被外部包 import 啦，比如 append 函数暴露了 slice 的底层实现啦，比如对 slice 做 for range 遍历的第二个元素其实是 slice 中对应元素的拷贝啦等等等等；这些问题基本上只能靠多写 & 多翻语言规范来解决了（不过有些问题语言规范也写得不是很清楚 😂）

总体上来说还是比较容易上手，开发效率的话还是得看具体的任务类型，写业务的话应该不会差太多

@drackzy 我一个 Python 党都觉得 Golang 表达力弱，习惯了 Ruby 灵活性的程序员写 Golang 得被郁闷死吧（以及为啥不考虑 Elixir 呢）

@l1093178 ruby 国内就 web 太窄，大厂太少。go 能进中大厂，技术想往底层发展。亲戚 gaode 测试年终奖都 20W 眼馋了

@l1093178
开始用的 glide 挺好的
dep 出来就跑去用
被 dep 坑了好多次。
但是现在已经好了。。。
最近一个月没出过问题了。

如果是对 qps，特别是计算性能有要求的话，用 golang 没错。
如果是像 web 开发这种主要是卡在 io 上的话，用 python 也没问题。
开发效率肯定是 python 高毋庸置疑，但是动态语言也对开发者的要求比较高，水平差的写出来的 python 真的是惨不忍睹，虽然也能实现功能，但是总有一天忍不了重构的时候才会知道痛的感觉。
其实说 python 的性能问题有点过时，毕竟实在需要的地方可以上 cython。
不知道有没有人知道 uvloop，这东西用起来感觉和 go 的原生已经差不多了。（当然和 fasthttp 还有差距）
python 最大的坑是绕不开 gil，要吃满 cpu 只能多进程，如果涉及到多进程通信又是另一个大坑。

@bookding libuv 这种配合 py 虽然性能够好，但是能写好这种异步很难，而 golang 提供了把这种细节隐藏在语言 runtime 里，更有利于大规模开发。

@yuchenyang1994 python3 的 async\await 语法已经比原来的 yield 好多了，只要脑子里有异步这回事，写起来其实还好。当然 golang 的 goroutine 还是厉害，尤其像 fasthttp 这种对 goroutine 做了二次优化的，的确要甩 py 几条街。
我觉得倒不是大规模开发就一定不能用 python，对于业务需求变化快的服务，用 py 写的效率可能是用 go 写的三倍，尤其是涉及到复用重构，或者是频繁更改接口数据的情况下（比如前端一天变三次 json 结构）。况且一般 web 业务的瓶颈都在 io，就算用 go 来写也不会有本质性的提升。

golang 可以让性能问题更晚爆发。就吃定了这一点而已。

那种从 cache/db/rpc 里读一个返回值丢到 http response 里的事儿，就应该 golang 来做。

如果性能瓶颈在数据库，用任何语言写区别都不大。投入精力换语言来提高性能，何不投入精力把业务好好设计一下，岂不是收益更大？

@Muninn 感觉 dep 的设计还是有点不适应，官方文档也还有点欠缺

@drackzy 这倒是，Elixir 国内也很惨（感觉比 Ruby 还惨）

@bookding 我本身是 python 开发，我真的不觉得 python 开发大型项目相对比 go 有优势，因为这只能是相对来说。动态语言一旦开发到一定程度，你会发现面目全非的业务逻辑，满天乱飞的全局变量，散落一地且毫无抽象的函数，见谁都恐慌的错误处理。要开发大型项目，这就十分依赖单元测试，但是说实话，很多人连基本容易测试的代码都很难写出来，单元测试覆盖率上不去，以后做重构，简直就是灾难。golang 相比 py 好的是他在工程上做了很多妥协，甚至不惜牺牲程序员的好感度， 譬如：令人蛋疼的错误处理， 简洁到没有三元运算符的语法，没有泛型等等。。。说到底，python 是一个非常信任程序员的语言，但工程角度来讲应该是不能相信任何程序员。

@yuchenyang1994 哈哈哈，面目全非的业务逻辑我也见过，这个深有感触。动态语言对于程序员自身的要求比较高，如果用 python 的话，代码 review 就更重要一些。
至于说大型项目，我也不知道我做过的项目规模够不够大，但是如果一开始就按微服务来写，控制好每个服务的规模的话，单元测试也就容易做得多了。
不过说实话，我也同意 go 在工程角度上比 python 更有优势，毕竟 python 从一开始诞生的时候也没想到会有今天这样规模的应用。而 golang 从一开始就是按照互联网工程来设计的，比如 channel 这种东西，只有写起来的时候才知道有多方便。

@bookding 嗯，所以问题来了。一般我们开发过程中，一开始我们用 python 快速实现，快速试错。因为有时候我们甚至不知道我们到底要做什么，能做到什么规模。但是一旦项目稳定了。人都是趋利避害的，基本上就不用 python 了。就比如说 asyncio 吧，是能极大提高并发，说实话做的好的话，并发性能甚至可能比 go 还要高。但目前看，即没有成熟稳定的工业框架，也没有大企业为其背书。况且目前发展水平来看也很难落实到工业应用上（我实在是不想吐槽 sanic ）。我觉得 go 值得学，甚至值得转。他不是一门让你写的爽的语言，甚至有时候会让你痛苦的语言。但却是把好用的锤子，干啥都干不好，但绝不会干坏的这种。

都要转了，，为啥不转 Java， 转 go 弥补 python 的那些问题，Java 都很好的解决了，直接上奔驰啊，要骑什么自行车

@q397064399 同样的疑问

@q397064399 大学里学编程的时候，被 java 版本的 hello world 一秒钟劝退

@yuchenyang1994 求吐槽 sanic

@shidenggui 想请教下 go 里面 celery 是如何替代的。