@EscYezi #19
首先，这写法似乎并没有比 sqlw 现在的样子更省事呀，兄弟你看我的示例代码。
而且 go 的泛型不是万能的，泛型适合具有同一类别方法的类型比如数值类，都可以进行基础的数学运算，然后泛型里不同的类型实例也可以加减乘除，但是如果你的逻辑里包括用泛型的数学运算但是你实际传的确实一个结构体进来，就不行了。c++那种泛型方便是因为可以操作符重载可以把各种需要的 class/struct 实现同类方法（ go 的接口能实现这种但是不能满足泛型的需求比如返回值的类型），而 go 没有操作符重载。对于未知类型类别的参数，sql 库里去做字段映射时，仍然是需要用 reflect 实现。

@liaohongxing go 事务的用法是 tx, err := db.Begin()，但创建 tx 后的执行多条语句也是由用户实现的、框架层不好去判断，正确的用法是创建 tx 成功后直接 defer tx.Rollback() 就可以了，后面如果 Commit 成功了、defer Rollback 执行时会失败但不影响正确的逻辑，defer tx.Rollback()还可以避免连接泄露，比如中途 panic 了、既没有 Commit 也没有 Rollback ，因为 tx 独占一个 sql 连接，只有 Commit 或 Rollback 后才会把连接放回连接池给其他地方用。正确用法参考：
github.com/lesismal/sqlw_examples/blob/main/tx/tx.go#L26
直接使用标准库同样也是应该这样子的，否则就存在泄露的隐患

@jam1024
如果按这个逻辑，那 c 语言早该被消灭了才对。然而并不是所有业务都是简单的 curd 。
另一个话题，curder 的收入也是个很难突破的瓶颈，要提升实力和收入，怎么办？固守所谓的使用高级语言？当顶流量级项目来临需要应对性能问题自己无从下手只能看着别人出手？
不能要求并期望所有人都只做 curder 的。

@jam1024 sql 与 ORM ，我觉得 @pastor 老兄 #12 这段虽然很逗，但确实又很贴切： “人家是门语言，你们却像嫖客一样上来对人家一顿胡搞猛搞、连自己做了啥都不知道，然后还说 ORM 真香，真是对自己对 sql 都不负责，妥妥的渣男。。。”

@jam1024
我没预料到兄弟你认为 ORM 比 rawsql 难、ORM 比 rawsql 更安全。关于这两点，我的感觉刚好跟你相反。

@pastor #12
其实其他那些 ORM 比较完善的语言，在做那些数据量不大的对性能没啥要求的项目时还可以的，比如学校的管理系统，公司的 OA ，这些通常单表都很小的没啥压力，用习惯了 ORM 的同行开发效率还是蛮高的

@jam1024 #14
比如 http 服务一个 routter handler：
1. 如果是只需要某个特定的表，直接用一些三方工具导出与表结构映射的 struct 拿来直接用就可以了，比如 model.User 结构体或者结构体数组拿来接收 Query 的结果
2. 涉及多表联查的，我们通常 router handler 文件里单独声明 struct 用于接收 rawsql 的字段，其实并不麻烦，而且通常规范点的项目，除了数据库的 model ，c/s 交互也是有规范的协议格式的，所以不管是 json 还是 pb 还是其他、不管是否联查、声明一个结构体这一步多数时候本来就已经存在于流程中了

@mcfog #6
sqlx 我没太用，自己以前主要是使用标准库 rawsql 。sqlx 、gorm 、xorm 也都简单看过他们的文档教程、还是挺复杂的，相比于使用标准库 rawsql ，这些 sql 库学习成本更高、姿势有点多反倒需要去注意更多问题。
sql 的主要操作，就是增删改查，标准库的查询用 Query/QueryRow ，其他的用 Exec ，非常简洁明了，麻烦的地方就在于 Query 相关的 rows 到结果的 Scan 。
sqlw 把遍历 rows 去 Scan 这些省掉了，中间的一堆 if err 也省掉了。使用 rawsql 能让程序员保持对 sql 语句的功能、性能直观和敏感、减少或者避免 ORM 背后行为那些隐藏的细可能导致拼接出来的 sql 不是自己想要的、甚至出其他问题，而且虽然不是 ORM ，但是执行语句与结果映射到结构体一步到位，还是很省力了。

@dorothyREN #7
go 完全避免 if err 是不太现实的，sqlw 帮助去减少了 for rows.Next{ rows.Scan }这些地方的很多 if err 。
另外，很多人对 if err 抱怨，却没去想过，go 这样使用 if err 让他们的代码更健壮了。相比于其他一些语言用异常处理错误，go 把错误、异常各管各的其实更清晰，只是很多人“先入为主”，用习惯了以前的某种姿势或者框架提供的方式、不想去改变成更合理的方式罢了。

@pansongya 混杂是指 sql 和 sqlw 同时？还好吧，sqlw 把 DB 、Stmt 、Tx 这几个都包装了下，使用 db.Prepare/Begin 返回的是 sqlw 的 Stmt/Tx ，Query 相关的写起来就都简单了，我再考虑要不要增加个 Insert 、Update ，怎么设计能保持简单与优雅。

mybatis ，java 和 go 真的是繁冗与简洁的两个典型了，所以我估计不会去模仿任何一个 java 相关的方案了 /手动狗头 。。

顺便推下自己另外两个库，详见旧帖或者我的历史帖：www.v2ex.com/t/794435

@realpg @pastor 二位看下这种可否节省些体力
@jinzhu 也欢迎 gorm 大佬多多交流指导

建议该新闻视频上《抖音》《 ticktok 》

建议该新闻上《今日头条》

PHP 永远活在 PHPER 心中，永垂不朽！

合格的巴氏鲜奶都可以，不只是几家大厂的，有些二三线小城市的小厂甚至口感更好

顺便祝愿蒙牛伊利去死

我也收到过：
https://github.com/lesismal/arpc/issues/32

他们好多营销用的号来 open issue ，过阵子这个号就 ghost 了
他们中间还有一些个人账号也留言来着但是很快就把个人账号的回复删除了

其实如果不是对单个仓库频繁来袭击也还好，毕竟也能帮助排查些安全问题

对于应用服务，internal 可能不是好点子，一旦多个仓库想共用，没法 import 它