can't agree more

e5 只认 intel, 01 推荐 sagami 😄

它们需要的是人矿需要的是狗子, 站着挣钱的它们当然不"敢"要
这不是 OP 的错, 没必要再在它们身上浪费时间, 下次面试优化下应对策略

概率上讲，不会是你喜欢的类型，因为好的早就该有主了且不太会主动出击

#6 该字段做索引

id 或者其他冗余字段, int64 或者 string, "是"则该字段为时间戳*10000 的 int64 或者对应的 string, "否"则是时间戳不加倍

查询"是"的时候查大于时间戳 10000 倍的位数的最小数值的范围

先有 c, 后来 bj 老爷子造了 c++
现在的 go team, 有 c++ 那味了

rob pike 和 c 爹两位老爷子年纪大了, 发起项目后应该就很少参与了, 过去的十几年主要都是 rsc 在弄.

最近 rsc 把 golang 交出来给其他人了, 不会是因为范型和 range over func 这些新特性被他放进来了吧? 如果是, 那他活该下课

官方可以支持新特性, 但我不会去使用的, 至少肉眼可见的短期内我不会去使用, 并且禁止我们公司的兄弟使用.

其他人用不用, 只能祈祷了, 我祈祷其他知名项目如果使用只用于内部实现, 不要放出来公共内容要求使用者必须去用这些新特性.

google 业务和人员的情况：
1. google 90%以上的收入来自广告，大多数业务是不挣钱或者亏钱的是研发未来
2. “大型科技公司过度雇佣人才是为了让员工能够参与到未来的项目中，并确保他们不落入竞争对手手中，有人将这种模式称为人才圈养” https://www.163.com/dy/article/J1LFIPFD05538CKG.html

> 接受 PR 就当表彰粉丝的热情了

@Nazz #11 我个人觉得 "表彰" => "感谢" 更好些

@mark2025 对呀, 所以我一直想不明白很多人号称 orm 比 sql 简单是为什么, 因为我一直学不会 orm. 不是看不懂 orm, 而是因为抵制 orm, 所以每次都不想学, 所以学不会. 要避坑 orm 先要学好多东西, 这本身并不比 raw sql 容易

@mark2025 其实我觉得还是 raw sql 简单点，orm 自己就一大套东西要学，然后不同语言不同 orm 框架都可能存在不同的表达、不同的隐式、不同的坑，但 raw sql 同一个数据库通吃，而且 sql 本身的表达能力远远比 orm 优秀。

@zzhaolei #93 不是回复我的，我之前没看到，可以看下我 #105 的，也可以看些其他帖子，比如 Xargin 的：
https://github.com/cch123/blog_comment/issues/254
还有一些其他帖子例如：
https://juejin.cn/post/7174222105788514334
https://studygolang.com/articles/23459

你可以看到一些 orm 、非 orm 优劣的对比包括 gorm 或者 xorm 的一些坑你都可以去搜下看看。单就性能风险这一点上，高阶一点的开发者基本上是达成一致的，orm 自己的泛型导致的性能损失都是小损失，最大的风险就是我在#105 说的，或者 Xargin 文章里讲的。只有没怎么经手过大项目的才会对 orm 这个坑人风险的说法这么不屑一顾

“我就是好奇，这些人张嘴闭嘴就是 ORM 有不确定性，到底有什么不确定性，自己测试过？还是踩过坑？还是说嘴一张一闭反正我不管，ORM 就是有性能问题？”

这个观点是你在自己现阶段水平下得出的结论，但当你以后技术进阶了很可能会自己推翻自己这个观点。如果对技术有追求，可以多试试大项目的工作。如果现在的工作项目量级对性能没那么大要求且钱多那就无所谓了，能挣钱就行，技术都是浮云

@zzhaolei
@XyIsMy

一是: orm 本身是二次加工生成代码，不是直接 sql 语句不直观。日志 level 的方式打印出来的在复杂 orm 使用过程中、可能随着输入参数不一样可能做不到线上所有情况的 sql 范式覆盖，而且 orm 还有一些隐式的东西不是程序员自己设定的，比如一些 orm 库处理数据库的 null 值还是什么来着, 需要额外去绕过，具体哪个库哪些坑我记不清了，各位可以自己搜索引擎搜下或者官方 issue list 去看，我因为抵制 orm 所以对 orm 也没深入研究
二是，这也是更重要的一点，orm 培养了很多程序员的使用习惯、抛弃了 raw sql ，我见过的绝大多数初级中级同行、以及多数所谓的高级开发（至少八年十年以上经验），都是只要 orm 能实现功能就搞上去了，性能神马的都是事后线上出了问题再去搞。比如上面说的日志 level 打印出 sql 来, 但很多人习惯了 orm 开发方式这种思维，即使打印出来也不会去关注 sql 性能相关. 咱国内人口基数大, 中等规模的公司就可能经常遇到数据量较大的量级, 在做这类项目的时候、尤其是 OLAP 涉及大量统计汇总操作的，一个没留神就被 orm 选手搞性能事故了. 跟这类兄弟共事, 为了避免这些, 研发流程上已经做了很多把关, 但仍瑟瑟发抖.

@qW7bo2FbzbC0 #71
interface 满天飞是当时写这些垃圾代码的人的问题, 不是 golang 自己的问题.
正确姿势本来就应该避免 interface 满天飞, 我看到很多喜欢搞 interface 满天飞的, 是 php nodejs 之类的转 go 的人居多, 这也不能全怪他们, 毕竟以前语言习惯已经信手拈来了, 刚开始未必能意识到这样会带来工程上的问题, 更何况有时候赶工只追求先搞定业务
c/cpp 或者一些新手上路就是 go 的, 姿势正常的人多些

接手别人的屎山不是 OP 的错, interface 满天飞不是 golang 的错, OP 要怪就都怪写屎山的人吧

@james122333 我这个就是简简单单几点:
1. 鼓励明确定义 table 对应的 struct, 用明确定义的 struct 操作 sql, 这个 struct 自己手写也好用工具生成也好, 都挺方便的
2. 鼓励 raw sql, 避免 orm 之类的可能生成了性能不友好的语句造成性能事故
3. 框架尽量自动映射/绑定 sql table 和 struct, insert/update/select 这些与 struct 映射绑定操作密切的都很轻松用 struct 操作
4. 奥卡姆剃刀原则, 不提供 orm, 不提供那么多没什么必要的垃圾接口