3000 多的东西, 他才赚了你 2000 多

单方面经济关系的人, 通常都不是真正的朋友关系, 你打游戏开黑不会找他, 你去桑拿洗脚泡妞不会找他. 这种是经济上的熟人罢了

真正的铁子朋友就是常见那几句:
一起同过窗
一起扛过枪
一起嫖过娼
一起分过脏
...

双人运动的时候对方情绪稳定
给她惊喜的时候对方情绪稳定
男人临终的时候对方情绪稳定
......

小伙子你这不叫延迟满足, 你这叫:

少年不知 X 珍贵, 老来没 X 空流泪

> 如果拿 js 来做对比的话，很明显 js 努力的方向一直是用同步的方式写异步逻辑，经过了 promise 到 async/await 的迭代，但 go 这边就很符合直觉。

对对, 非常同意. promise 对于很多人都是个坑, 因为看着是顺序的实际上不是本次 eventloop, 所以遇到 for 循环里的 promise 或者 promise 后面的逻辑, 其实都是违反时序直觉的, 很多新手遇到了 bug 都仍然难搞懂这个. async/await 虽然提供了, 但也是难于理解难于使用, 比 goroutine 自动档差远了

这么有毅力不容易, 加油 OP!

> Go 最重要的贡献之一是基于 chan 的思维模型：Share memory by communication 。
> 日常反复被强调的 goroutine 其实不重要，很多语言也可以有样学样。

chan 挺好, 但本质上相当于个阻塞队列, 即使没有 golang, pipe/cond_t+mutex/sem 之类的传统的进程间通信/线程同步的这些也都能实现类似的阻塞队列组件. 但多进程多线程和这些 syscall 要么阻塞线程要么异步.

Share memory by communication 更像是从 erlang/actor 拿来的, 但 golang 整个语言本身没有像 erlang 那样纯 actor.
actor 是个太监模型, actor 之父是为了他们自家电信业务造的 erlang, 电信的那种每个 erlang 进程处理一个连接, 设备进行管理功能也不算复杂不需要连接之间有复杂的交互, 这种场景用 erlang 的进程通信比较简单.
但纯 actor 并不适合于复杂的业务, 例如连接之间有复杂的交互.
而且不管哪种 actor, 让一些即使很简单的交互, 或者一些用普通的逻辑处理比较简单的交互, 也都强制必须用通信的方式, 都是需要数据拷贝/调度或者切栈上下文之类的, 这些都带来了额外的性能损失. 性能损失这一点, chan 也是类似的, 简单的有性能需要的功能, 用 chan 未必见得划算.

runtime 基础之上:
goroutine 让大家绝大多数时候能写同步代码, 这个解决了传统高并发高性能的 c/c++/java netty/nodejs 等语言的 callback 逻辑不直观和 callback hell 的问题.
传统的进程间通信/线程同步 syscall 封装组件, 即使实现同步组件, 但阻塞的是进程/线程, 所以不能用 goroutine 与这些 syscall 结合来让大家写同步代码, 所以需要 chan 这种基于 runtime 的轻量阻塞队列实现.

golang 标准库提供了个基于 runtime 的 cond_t 也可以自己封装下实现 chan 或者类似的组件, 但 chan 已经足够方便了, 我暂时想不到有需要自己搞这个的需要.
从这些角度讲, 我觉得 goroutine 仍然是最重要的; chan 很好, 但是次之, 因为也有很多场景是不需要甚至不适合用 chan 的.

我个人觉得 Java 开发效率是最低的.
—— 但这只是我个人对我个人用 Java 的感觉, 而不是我认为所有人用 Java 都如此.
—— 至于原因: 我个人不喜欢 Java 的臃肿, 所以一直抵触用 Java, 所以也没有学习过 Java 的那些框架.

很多说 Golang 开发效率低的人, 其实跟我类似, 首先他们嫌弃 Golang 提供的语法糖/特性太少, 其次他们也不熟悉 Golang 社区的成熟框架/解决方案. 而且这些人绝大多数都是做 CURD 对性能没太大需求, 所以带来的性能提升他们是睁眼瞎一样完全忽视.
他们从来没考虑过是不是因为他们自己都不够熟悉 Golang 的正确姿势和成熟方案, 而仅因为 Golang 没有其他语言的那些姿势和方案, 就来无脑喷 Golang 开发效率低.
这种类似的观点言论, 可以反映出他们自己的水平还不够高, 但我这里说他们水平不够高并不是贬义, 因为这些人很大一部分是经验年限比较少的, 多数人年轻时候都菜, 慢慢成长吧, 等自己真正脱离了 CURD 这个 Level 的时候, 真正懂得去思考系统和工程的时候才能给出客观评价.

设计模式的糟粕害人挺多的, 观察者是少数实用的之一, 和发布订阅本质上是类似的.
没必要把自己陷在某个语言的实现方式上, 理解它的用途, 融会贯通的实际运用就可以了. 我当年写 C 为了模块之间解耦自己就搞了个出来, 当时都不知道这玩意是个设计模式, 后来看设计模式的书才知道原来这叫做观察者.

BTW, 至今设计模式我也没记住几个, 反倒让自己代码通常比多数人更简洁一点.

@lesismal #59 https://www.moomoo.com/hans/news/post/36558404?level=1&data_ticket=1735026819434878

遇到过被颠得屁股离开座位, 还遇到过窗外电闪雷鸣电光带着火光旁边小妹妹直接哭了, 所以感觉 OP 这种还好

另外, 这几年波音的新闻可是没断过.
根据之前报道, 波音近些年, 搞财务之类背景的人上位, 挤走了技术出身的管理层, 大搞降本增效才有今天的成果, 飞机生产和生命周期长, 这玩意可不是三五年就能整改好的, 建议避坑波音

个人感觉感觉好多人把概念和用途都搞混了，说说我的浅见总结


什么是重放？
用你的原始请求数据原封不动地再发一次或者多次，别人只需要知道原始请求数据、再次发送即可，不需要猜测 nonce 不需要破解加密算法等


防止重放攻击的主要维度：
1. 幂等
比如金融或者其他涉及资金之类的业务，订单 ID 本身的幂等性是最基础的，已经实现了幂等的功能即使被重放也只是消耗算力
2. 时间
如果服务端对访问的时间有效期不做限制，那么任何一个请求数据被保存下来之后，任何时间都可以再次用这个数据进行请求；
所以，防范重访攻击的基础，是对请求时间有效性进行限制和校验：每个请求应该带上时间戳，服务端对时间戳与服务器时间做有效性校验，比如时差超过 30 秒认为请求不合法。


以上两点以外的其他防范，例如猜 nonce 算法、破解加密算法之类的来伪造请求内容，本身已经是生成新的请求了、跟重放的字面含义就已经不符了。
所以，严格来讲这些不应该归纳为重放，而是应该属于密码学范畴的攻防扩展了，例如：
1. crypto ，内容加密，对称非对称不同等级
2. sign ，不同 hash 算法验签
3. nonce ，加盐

@nexo #47
1. 我没有下定论, 也没有否定色弱考驾照这件事
2. 帖子偏向庆祝与鼓励的气氛, 但并没有首先明确自身分辨信号灯是否完全没问题
3. `色弱中的很多人可以分辨也可以考驾照` 不等于 `每个色弱的人都适合考驾照`, 仍有一定比例严重色弱的人不适合考驾照

我只是建议 OP 先把自身情况说明, 基于自身分辨信号灯没影响的前提下, 庆祝和批评官方机制不合理都没问题, 并且也不会导致每个色弱的人都盲目跟风去考驾照.

看到帖子内容, 第一感觉是对于色弱人群不分青红皂白的鼓动/鼓励, 毕竟别人卡得严也是为了大家尽量更安全一点

个人觉得应该先重点讲自己对交通信号灯分辨能力没问题, 以这个为基础再用这种帖子鼓励类似的朋友比较好

性教育也是教育, 只是有点突然罢了

十几年来研究了好几次什么是依赖注入, 今天又研究了下, 至今没搞明白到底什么是依赖注入...