说 Go 语言写不了业务逻辑的请进

[Hanggi]

并不打算引战，单纯出于好奇。

https://github.com/gin-gonic/gin
https://github.com/beego/beego
https://github.com/labstack/echo

把前几名的 Go 语言后端框架加一起都 10 万星了。

https://github.com/spring-projects/spring-boot
https://github.com/laravel/laravel

Gin 6 万 1 ，spring-boot 6 万 2 ，laravel 7 万。
虽然不能说明一且，但至少说明很多人在用。

---

首先强类型语言灵活性肯定是不如脚本语言的，所以没必要争个高低，PHP 、Node.js 、Python 这类脚本语言写业务逻辑能力是最强的。

但在可维护性上，强类型语言是比脚本语言好很多，所以 Typescript 的可维护性是远胜于 Javascript 的。

---

回到 Go 语言，
首先要明确的是 Go 语言是一种为了最大化编译速度而牺牲语言特性的一种语言。

很多人说 Go 语言写起来痛苦，说的其实是那些理应支持的语法糖或工具函数在 Go 语言里并不提供，而需要自己去写所带来的痛苦。不提供不意味着无法实现，只是让你用最基础的语法结构去实现，换来的是更快的编译速度和非常低的阅读门槛。

对于 if err != nil 只说一句，Error 是一种值。
https://go.dev/blog/errors-are-values
（过去也有人提议加入 Try Catch ，但都被否决了）

---

最后，还是要看你的需求是什么，Go 语言写业务逻辑可能不是最佳选择，但确实很多人在用 Go 写业务逻辑，它的特性满足了一些人的需求，特别是在云原生领域。

说写不了的，可以把你的场景细节分享出来，
解决方案都是有的，接不接受是每个人自己的选择，但是光说 Go 语言写不了业务逻辑，又不说到底是什么场景。
谁能知道到底是 Go 语言写不了业务逻辑，还是你的编码或理解能力上有不足呢？

[luob]

冷知识，（ ）也是能吃的

但是作为一个灵长类人科人属人种生物，实在没必要花大力气证明这件事，要不然会让大家怀疑你的身份。

[yedanten]

写不了业务 x
写 curd 很痛苦√

如果把写业务=写 web 应用，那确实可以说，不建议

[tairan2006]

能用和好用不是一个概念，用 C/汇编啥都能搓出来。

golang 在复杂业务这块生态缺失是很显然的，你连个好用的工作流引擎都找不到吧。

[BBCCBB]

c++也可以写 web, 但能用和好用是有区别的

[BeautifulSoap]

其他感觉还好，但 Go 写 Entity 到 DTO 之类的转换写到吐血是真的

[wangyzj]

@tairan2006 #3 就工作流引擎这块
所有语言的工作流找来找去最后还是 java 的 activiti 家族最好使
虽然我也不明白为啥

[neteroster]

没人说写不了吧，都是图灵完备的啥业务逻辑不能写？关键是能写和能写得好，能写得快，能写出可读性高和可维护性好的代码中间是有距离的。

[Hanggi]

@BeautifulSoap 一个结构体，定义好 tag ，一行映射不就解决了吗？

[Hanggi]

@tairan2006
@BBCCBB
所以 Go 语言写业务逻辑是跟 C/C++/汇编是一个级别的是吗？
那为什么 Go 语言写？用 C/C++ 写出来不是性能更好吗？

[Hanggi]

@neteroster
所以 PHP ，Python 能写出高可读和高维护性代码，Go 语言写不出来是吗？
是语言问题呢，还是编写的人的问题呢？

[yuk1no]

流量密码行哇

[Curtion]

不是在说写不了吧，任何一个图灵完备的编程语言只要想写都能写业务，只是区别在于合不合适。 说 Go 不适合是相较于其它的解决方案来说的。 至于说写不了的人，那肯定是乱说的，Go 是有一些特殊业务领域比较好用。

[tairan2006]

@Hanggi 你要不要看你帖子里自己问了啥…最后一段。

你这反问搞得我只想 block 你…你看你这回复的几楼，全是反问，攻击性这么强想干啥。

[lix7]

开头说不打算引战，最后人身攻击，可以，block 了

[Mexion]

有人说过不能写吗，不都是说写的很痛苦吗？这么说 c 语言也可以写啊，为什么不用 C 语言写

[fkdog]

问一下，还花时间在编程语言这个级别上 battle 的，一般都是毕业几年的啊？

[XCFOX]

我个人感触比较深的是 ORM 场景。C# 有 Entity Framework 、TypeScript 有 TypeORM 、MikroORM 、PHP 有 Eloquent 、Kotlin 的 Ktorm 。看过了以上 ORM 再看 Go 的 ORM 实践就很一言难尽。

优雅的 ORM(TypeORM)是这样的：
```
const article = await articleRepository.findOne({ title:"Tales of Ten Worlds"，published:true });
```
从 文字表里取一篇文章，取出来的变量直接从 findOne() 函数里传出来，非常顺畅。

Go (gorm) 语言是这样的：
```
var article Article
db.Where(&Article{Title: "Tales of Ten Worlds", Published: true}).First(&article)
```
先声明 article 为 Article ，再传指针到 First() 里，一下子打破了函数式编程的 「没有"副作用"」「不修改状态」的教条，这里将 article 的类型改为其他也不会有编译时错误。

或者这样(ent)的：
```
article :=client.Article.Query().
Where(article.TitleEQ("Tales of Ten Worlds"),article.PublishedEQ(true)).Limit(1)
```
这样确保了编译时类型安全但将查询条件改成了指令式的罗列，极大损失了简洁性。

[agdhole]

楼上提到了 ef core ，底层用 linq 去操作 sql 或者 list 等等，体验好太多了

[FreeEx]

我感觉主要是因为写 web 应用没有一个最佳实践出来，写起来比较痛苦，尤其是新人进入团队去改之前的代码。

例如

目录结构怎么划分？
是搞全局函数还是结构体挂方法？结构体挂方法的话如何实例化？结构体直接有依赖关系怎么实例化？
db 是全局的还是通过参数传递？
需不需要分层 ApiHandler 、Service 、Repo ？
...

问题太多了，不说每一个公司吧，就说每一个项目，都可能是不同的项目结构，百花齐放，I am happy :)

[wonderfulcxm]

> 很多人说 Go 语言写起来痛苦，说的其实是那些理应支持的语法糖或工具函数在 Go 语言里并不提供，而需要自己去写所带来的痛苦。不提供不意味着无法实现，只是让你用最基础的语法结构去实现。换来的是更快的编译速度和非常低的阅读门槛。

恭喜你找到了痛苦之源，而且你那么痛苦实现的功能，人家语言就自带了，质量还更好，你说气不气人吧，如果喜欢自虐，欢迎使用 go 语言。