先有 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, 不提供那么多没什么必要的垃圾接口

@james122333
1. orm 是非常不好的选择, 中小项目倒是还可以, 大项目大数据量的, 用 orm 存在一些不确定性可能导致性能风险, 所以我都是禁止团队试用 golang orm 的
2. 还有生成代码的 sqlc 这种, 性能当然是最友好但用起来也有点麻烦, 因为一些业务是上下文比较复杂的, 单纯生成一段 sql 对应的 go 代码还需要 ctrl cv 而且还要修改对应的地方, 功能修改的时候比较麻烦
3. sqlx 简化了一些 binding, 但也把一些简单的复杂化了, 比如又有 Select 又有 Get, 比如 Insert 缺少 struct 的自动绑定(我没深入使用只是看它文档和例子), 综合下来我觉得它少了一些可以真正节约体力的但多了不少没必要的, 所以对我来说病不好用

所以以前还是继续标准库 raw sql, 直到我实在忍不了标准库 raw sql 自己搞了这个

定义跟 sql table 对应的 struct 是必要的, 自动绑定后用 json 去操作 struct 就没这个问题了.
个人觉得 orm 不好用, 自己搞了份 raw sql+自动绑定的库, 有兴趣可以试试, 例子:
https://github.com/lesismal/sqlw_examples/blob/main/mysql/db/db.go#L101

这种纯数据结构本身就不应该设计成返回 error 的，其他语言这种数据结构也没见过返回 error 之类的啊。。：
https://github.com/golang/go/blob/master/src/container/list/list.go

A1 这种直接查 map 就行了，无需遍历

### 查表法
1. A2 这种涉及顺序的，可以使用查表的方法：
开奖结果的 hash 值作为 mapA 的 key ，因为是 5 个数字而且彩票这种数字通常不大，一个 uint64 甚至 uint32 就足够做 hash 值了。每个奖期信息作为 value 并且排序后的数组作为 map 的 value 。如果用 c++，multimap 内部红黑树自动就是排好序的，不需要自己排序数组之类的

假设不同的下标为 targetIndex=0, 然后就只要查 map hash 值得到相同的、如果不等于 targetIndex 就找 targetIndex=当前 index+1 并查找下一个 hash 相同的。当然，如果遍历平均为 5 、开销也不大, 那这种可能不划算、根据实际测试情况、可以考虑就用遍历

2. Q15B/Q15R/P15B/P15R 这些，都可以用对应期段的数据建各自对应的表，然后直接查表就能计算出 key 对应的 value 数量，不需要遍历几十期、匹配上则+1 的方式去计算

这个过程中只建表一次，然后上面的 1/2/3 都是直接查 map 就出结果了

### C618
建表的过程可以同时根据期号做倒排索引，C618 回退 618 期、计算每期时，把上述过程中建表的只需要删除临界的一期、加入需要的一期，所以这个过程中不需要重复建整个表，只是滚动删、增一期，整个流程的建表开销不需要太大


我不了解实际需求，以上仅供参考

搜了下:

安卓的历史始于 2003 年 10 月，远在智能手机这个名词被广泛使用之前，也比苹果发布第一款 iPhone 和 iOS 早几年。其四位创始人分别是里奇·米纳、尼克·西尔斯、克里斯·怀特以及我们较为熟悉的安迪·鲁宾。援引当时鲁宾的话说，安卓是为了开发“更智能的移动设备，更了解用户的位置和喜好”。

鲁宾在一次演讲中透露，安卓最初是为了改进数码相机的操作系统。但即使在当时，数码相机的市场也在萎缩，仅仅几个月后，他们就决定将安卓的定位转向在手机内部使用的操作系统。

@xliao #9 文章开篇说明作者身份 "I was a young..." , 年轻人水平不够的阶段随便搞这种重构确实容易坑, 所以他的文章不能说明 rust 不行.

> 大内存，这点 go 做的不好，固定频率的 GC 在大内存占用时停顿明显。毛刺明显

go 的 gc 已经很丝滑了, 多数人的业务量也不会有瓶颈. 我这里的百万连接的对象 map 优化下确实省不少:
https://github.com/lesismal/nbio/pull/304#issuecomment-1583880587

其他很多场景也可以定制数据结构针对性优化 gc

至于调 gc 参数, 对于一些常驻对象数量大的, 仍然不太好解决根本问题

转:

YouTube 似乎在测试服务器端广告注入以对抗广告拦截器

YouTube 通过服务器端广告注入继续打击广告拦截工具。广告拦截软件 SponsorBlock 的开发者今天分享说：“YouTube 目前正在测试服务器端广告注入。”从高层次来看，这意味着广告现在是作为视频的一部分，被流式传输到你的设备，而不是单独投放到桌面网页或移动客户端。目前的方法允许广告拦截器拦截并且不显示广告。但未来广告会与视频无法区分。目前该功能仍在测试中，部分用户已经遇到了这个问题。