@w568w 1 这点没得洗. 但 2 这点, 带 gc 的语言一般都没有用 raii 这套的 (对象销毁时机不确定), try 这一套不太好表达把 ownership move 到其他函数这一点. defer 这玩意只能说有优点也有缺点

@hez2010 另外 java9 中已经废弃 finalize 了

@hez2010 这玩意真没法兜底. 可能会出现没触发 gc 资源就因为没有及时释放就耗尽的情况
cpp/rust 里头的 RAII 能保证这个 obj 离开作用域就销毁

@kxct 似乎只有不带 gc 的语言才有析构函数, 带 gc 的语言里头, gc 的时机不确定, 导致析构函数调用时机不确定. 没 gc 的话, 又一堆操心事

能先说出在你们这种场景下, 为啥两套集群不合适比一套集群更合理吗 ?
实际上, 也有人主张用多个小规模 K8s 集群的联邦代替一个大 K8s. 比如: https://www.infoq.cn/article/lgzz3duliciczvoibpxh

ps: 想起了罗素的一句话: 未受哲学熏陶的人，一生都被禁锢在种种偏见中，这些偏见来自常识，来自他那个时代或民族的习惯性信念，来自未经审慎理性的合作或同意而在其心灵中形成的信念。对这样的人来说，世界往往变得明确、有限、显而易见；寻常的事物不会引出问题，**陌生的可能性会被轻蔑地拒绝**。

动手实现一遍, 之后压测试试呗

感觉可以并行来跑, 充分利用 CPU 多核. 启动多个线程, 每个线程同时做 topK, 最后 merge 成一个

直接用 adblock/uBlock 之类的东西屏蔽了呗

瞎翻了下, 感觉没提到啥设计哲学. 比如可以说说以下问题. 如何实现是一个有意思的问题, 但在语言设计上选择要实现 X 这种特性而非 Y 特性也是个有意思的问题.
+ 为什么 go 没有 Java 中的异常机制, 出现异常的时候选择返回 err 而非抛出异常 ? 这是不是一个好的设计 ? 异常有啥问题
+ 为啥 go 没有一般意义上的继承 ? 如果没有继承, 如何实现多态 ? embedded struct 算不算继承 ? 一般意义上的继承又有啥问题 ?
+ channel 跟 Java 中 BlockingQueue 又有啥区别 ? 通过共享内存实现的并发跟通过 channel 实现的并发在哪种场景下更好 ?
+ 为啥 channel 会有 close 这个操作, 在哪些场景下会用到这个操作 ?

另外讲闭包的时候, 可以提下如何让函数实现一个接口.

你为啥实际试试呢 ?

@gdfsjunjun 有时会要求双击电源键确认, 起码 appstore 是这么处理的

如果向 master 内写了 x=1, 写成功之后 master 挂了(其它节点, 拿不到最新的 binlog). 这时候从其它节点读 x, 能读到 1 还是之前的值 ?

raft 能提供这种线性一致性的保证

@AoEiuV020JP 我仅仅说你提供的这个封装不适合处理这种情况, 没说 golang 没提供这种处理. io.Reader 就是一个流

@AoEiuV020JP
> 高级一点的现代语言都有封装一些方便的方法，比如直接把 body 完整读取转成字符串并 close
我的意思是, 这种封装挪到第三方库就行了, 没必要放到标准库, 这东西的使用场景很有限. 流式读取的应用场景更广泛, []byte, string 都可以看作是流


ps: **请你好好说话**

我觉得很合理. `resp.Body` 就是个 reader 跟 fileReader 类似, 区别就是这是别人帮你 open 然后把 ownership move 给你, 负责 close 是用户的事, 你觉得 fileReader 必须 close 是不是合理的 ?
虽然对于大部分调用 rest api 的情况, 是把 reader 内的读出来, 之后 close. 但是对于需要流式获取的场景并不合适(比如: 实时视频流, 大文件), 按我的理解, 进入标准库的东西, 得适配普遍的场景, 而非 rest api 这种单一场景

@AoEiuV020JP 如果是个文件呢 ? 直接读到内存里, 没准会 OOM

@SSang 似乎可以这样,
```
middlewareA:|________________________将 user_id 等信息放入 ctx______________________|
middlewareB: |____________________________log__________________________|
middlewareC: |_________________如果没有 user_id 报错_____|
```

@SSang 似乎可以这样,

middlewareA:|________________________将 user_id 等信息放入 ctx______________________|
middlewareB: |____________________________log__________________________|
middlewareC: |_________________如果没有 user_id 报错_____|

建议还是把鉴权放到 log 之前. 向 ctx 里头塞指针, 万一有地方把指针里的值改了, 很难 debug, 不如让它不可变