Golang Go语言有哪些框架
Golang Go语言有哪些框架。
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 语言写不了业务逻辑，还是你的编码或理解能力上有不足呢？
Golang Go语言写不了业务逻辑？请进
更多关于Golang Go语言有哪些框架的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
不是在说写不了吧，任何一个图灵完备的编程语言只要想写都能写业务，只是区别在于合不合适。 说 Go 不适合是相较于其它的解决方案来说的。 至于说写不了的人，那肯定是乱说的，Go 是有一些特殊业务领域比较好用。
我个人感触比较深的是 ORM 场景。C# 有 Entity Framework 、TypeScript 有 TypeORM 、MikroORM 、PHP 有 Eloquent 、Kotlin 的 Ktorm 。看过了以上 ORM 再看 Go 的 ORM 实践就很一言难尽。
优雅的 ORM(TypeORM)是这样的：<br>const article = await articleRepository.findOne({ title:"Tales of Ten Worlds"，published:true });<br>
从 文字表里取一篇文章，取出来的变量直接从 findOne() 函数里传出来，非常顺畅。
Go (gorm) 语言是这样的：<br>var article Article<br>db.Where(&Article{Title: "Tales of Ten Worlds", Published: true}).First(&article)<br>
先声明 article 为 Article ，再传指针到 First() 里，一下子打破了函数式编程的 「没有"副作用"」「不修改状态」的教条，这里将 article 的类型改为其他也不会有编译时错误。
或者这样(ent)的：<br>article :=client.Article.Query().<br>Where(article.TitleEQ("Tales of Ten Worlds"),article.PublishedEQ(true)).Limit(1)<br>
这样确保了编译时类型安全但将查询条件改成了指令式的罗列，极大损失了简洁性。
我感觉主要是因为写 web 应用没有一个最佳实践出来，写起来比较痛苦，尤其是新人进入团队去改之前的代码。
例如
目录结构怎么划分？
是搞全局函数还是结构体挂方法？结构体挂方法的话如何实例化？结构体直接有依赖关系怎么实例化？
db 是全局的还是通过参数传递？
需不需要分层 ApiHandler 、Service 、Repo ？
…
问题太多了，不说每一个公司吧，就说每一个项目，都可能是不同的项目结构，百花齐放，I am happy :)
想用你就用呗。
至于 Star 的数量问题。你可以搜一下，什么叫“劣币驱逐良币”。
你觉得 10 块钱的冰淇淋币 2 块钱的好吃，可能是因为你压根没有听说过有 100 块钱的。
第 1 点，因为 go 使用 github 作为依赖仓库，所以 repo 的 star 数普遍偏高。
go web 框架普遍使用 :param 作为路径参数（[API design guide - Google Cloud]( https://cloud.google.com/apis/design/custom_methods)），比如你上面说的 gin ，所以我 star 了 gin 但不用它。
>>> 很多人说 Go 语言写起来痛苦，说的其实是那些理应支持的语法糖或工具函数在 Go 语言里并不提供，而需要自己去写所带来的痛苦。不提供不意味着无法实现，只是让你用最基础的语法结构去实现。换来的是更快的编译速度和非常低的阅读门槛。
这点真的有人赞同吗？
接手一个项目还要去看前人封装的数据结构。以及对应的 api ，换一家公司还要重新熟悉
我写 go 跟写 php 一样，平时就 curd 多，现在一年下来了，内部积累的代码有时候可能比 php 还快了。
贴一段 go 代码, 有差别吗
// 读取列表数据 select * from users where id > 1 and create_ed >= now() limit 16
users := NewOrmUsers().WhereIdGt(1).WhereCreatedAtGte(database.Now()).Limit(15).Get()
fmt.Println(users)
https://github.com/go-home-admin/go-admin/blob/main/app/entity/demo/user_test.go
我还在上大学的时候看到部分公司开始使用 go 进行编写基础组件，感觉挺不错的。
毕业后开始参加工作接触到金融业务复杂系统，就这，想不懂为什么用 go ，kpi or okr boy ？
这明显胡说八道了，不是说写不了，是写起来不 happy
我们的产品是用 C++ 写 web 的
上家公司是 C 写 web
不是不能写，是工作量明显高于那些 web 专用语言
Go 真要适合，你就不会来这么努力去证明了。有这精力还是好好去贡献点代码把，为 Go 社区做点贡献。到了真正强大的时候，不用你辩解大家也都会认为 Go 可以写复杂业务逻辑了。
#31 对公司而言，人力也是资源，也是流动的。接手一个项目本来就要熟悉之前的封装，除非你一直都只写最基础的业务。别人经验我不清楚，但是 Go 的门槛确实低，基本上业务层面上封装概念搞懂就行。拿 Python 举例，我见过比较恶心的一些例子，使用类似 flask 的 requst 绑定线程的变量，数据结构全程动态生成，一些自定义的装饰器，locals()获取当前变量名当作 key/value ，诸如此类等等等等。每次碰到这些东西，我就觉得 Go 设计太特么好了
答非所问，所以追问而已，如果觉得有攻击性，那我先说声抱歉了。
我也说了，不管是痛苦还是什么，把场景说出来，分享一下。
不是说我要去评判，而是分享出来，大家探讨一下。
说人身攻击是指“编写的人的问题呢？”这句话吗？
代码的质量跟编写的人经验和习惯相关（也跟项目进度等很多因素相关），
如果用 PHP 老手和 Go 语言新手写出来的代码比较可读性，其实意义也不大，毕竟 Go 语言比较新。
有人说过不能写吗，确实有人说了没法写，这也是我的疑问点。
对于 C 语言，Go 的定位其实并不适合和 C 语言比较，且如果 Go 语言编写体验跟 C 语言差不多，那为什么要用 Go 语言呢，因为 C 语言性能更好。
问题背景很简单，
很多人说 Go 语言写不了业务逻辑（或者写不好，或者写起来痛苦），
但是又有很多人在问，有个项目到底用 Go 还是 PHP （或者 Java…）
也就说明，有一些人，他看到 Go 语言很火，并且在后端领域有很多应用，想加入 Go 语言生态，
但是又看到很多人说 Go 语言写不了，不适合写业务逻辑，而感到迷茫。
所以，我发了个贴，希望那些说 Go 语言不适合写业务逻辑的人，
把你们的场景分享出来，看看问题到底出在哪里。
#52
我觉得你可以把你认为写的优秀的业务代码示例贴出来，给大家学习一下应该如何优雅地写。
只让别人分享代码，然后你轻描淡写一句“是你代码写的烂”，这没法让人信服吧？
- Go 语言性能高吹的成分居多，你列的 Gin 在 TechemPower 的排名里面排第 63 位，是第一名性能的 23%。Fiber 框架性能在 Go 里最高，然而 Star 不如 Gin 。整个 Go 的平均性能可能和 Java 差不了多少… 说 Star 数多少多少真心没啥意义…… Go 这么火，你还是要搞清楚一点不是他语言多厉害，纯纯的就是微服务撑起来的。
2. Go 还可维护。动不动就是 codegen ，类型系统不是简约，是简陋。天天就是 if err != nil ，快赶上 C 了。隔壁 Rust 比你 Go 更 native ，怎么人的 Result 类型这么正常。都是现代语言，不要求你多高雅，正常一点总行吧。if err != nil ，这种模板代码，真的和 Java 里判空一样啰嗦……
没有 native 命，却患 native 病，是对 Go 语言最好的描述。
—
你用 Go 写写中间件挺好的，没人反对你。硬要扯业务代码全都用 Go 写，这不自虐。
确实 ORM 这块有这个问题，
Typeorm 的查询方式感觉依然是弱类型，要么包一层 interface 不然也是有写错的可能性。
GORM 确实有不少槽点，但是不管代码量还是心智上并没有太大负担（个人感觉），因为变量是未初始化的。
不知道你怎么想。
ent 的话通过 code generation 解决了类型安全问题，但是灵活性上也确实有损失。
但是比起用 xml 定义这些，感觉这种方式还是可以接受的，至少编写起来没有太大压力。
你这段话攻击性还是挺强的，本来这种话不太回的，就回一次。
k8s 那么复杂一个系统，调控那么多容器，去除底层的一些 low level 逻辑，给用户提供的接口是没有业务逻辑的吗。
难道只有 CRUD 才是业务逻辑。
还有，好多人说什么 Go 吹，Go 粉，这种论调其实挺无趣的。
写过 Go 语言的人哪个不是从其他语言过来的，现在已经很少有人会站某一门语言去怼其他语言，因为你站的语言和你怼的语言你都会，跟左右互搏有什么区别呢。
只有那些只会一门语言，生怕自己的饭碗被抢走的人才会如此敏感吧。
没什么其他意思，只想就事论事，讨论讨论问题，如果伤害到某些人，先说声抱歉。
希望不要把问题带到奇怪的方向。
事实上这不是 ORM 的问题，本质上是 Go 这门语言的问题，Go 由于追求极致简陋抽象能力太差，支持的特性太少，在使用中可能遇到：要么多写大量重复代码，要么各种转型，要么丢失安全特性变成动态语言，要么各种 for 循环等等等…太多了，我都不想一一点出来，实在丑陋繁琐至极，毫无优雅可言，然后就是特性弱就算了，还非要强吹设计哲学，实际上挫的不行。当然，我也不否认 go 有它的优点，go 生来就不是做 web 的料，在它擅长的领域发光发热就好了，你要说做 web 可不可以，当然也可以，最重要的一点就是：又不是不能用！
> const article = await articleRepository.findOne({ title:“Tales of Ten Worlds”，published:true });
论优雅 Rails 还真没怕过谁。article = Article.find_by title: ‘Tales of Ten Worlds’, published: true
Java 库的 github star 数量确实偏少。当年各种 Python 都好几万 star 的时候，Spring 的 star 才几千。
不过 star 多并不能说明适合写业务逻辑，仅能说明这个库比较 成熟 or 热门。
web 方面，现在 Go 语言在性能上也已经比不过 php 了，看最新压测排行的第 35 位 https://www.techempower.com/benchmarks/#section=data-r21&test=fortune
#58
TypeScript 的类型系统是十分强大的。得益于 TypeScript 的装饰器与泛型系统，TypeORM 的查询参数是强类型的，无需包一层 interface ，在编译时就会有类型检查。
相比之下，go 要实现比肩 TypeScript 的类型安全 就只能参考 ent 这种 code generation 的模式。
OP 如果搞得明白会在语言帖子里吵起来的都是些
1. 没有权限或能力控制选型
2. 搞不明白自己的系统需要什么特性
3. 只接触过两三种语言写过一两种范式
的人，就不会发这个帖子了
「为什么用 go 写 web 」跟「为什么用 js 写 arduino 」 是完全一致的问题，想想为什么后者没人吵
C# EF Core
var article = await context.Articles.FirstOrDefaultAsync(x => x.Title == “Tales of Ten Worlds”)
我觉得业务问题倒是其次，之后可以通过迭代来增加功能以解决这些问题。
go 现在最大的问题是过分依赖 github ，这是从语言层面的依赖，更具体一些，就是产品定位。
作为一个工具，肯定不能去依赖一家商业公司来实现某些功能。没有哪家公司或者开发者会希望明天 github 没了，go 就不行了。这跟 serverless 的包袱几乎一致了。
