我个人觉得 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 先把自身情况说明, 基于自身分辨信号灯没影响的前提下, 庆祝和批评官方机制不合理都没问题, 并且也不会导致每个色弱的人都盲目跟风去考驾照.

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

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

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

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

@charles0 #152 叫 goroutine 没毛病, 但是打字中文的时候协程比 goroutine 快, 而且很多人约定俗称都这么叫了, 日常讨论, 何必搞得学术氛围甚至法庭审判那样? 你们好几位出来说这个, 我反向建议下你们在实际生活中要灵活, 否则方言俗语一切约定俗成的谬误的词汇就都不能说出口了, 这样的活法, 会很累而且并不会对交流效率带来提升, 反倒会因为这种死板给更多遵循约定俗成的人带来麻烦, 让大家交流效率更低

@lesismal #151

甚至, golang 的 GMP, 我都忘记了, 要说 10 年 8 年 5 年甚至 3 年前, 应该都还记得, 但是现在都不记得了, 刚才回复 @Kauruus 也是临时搜了下 GMP 才又知道了个大概.
而且这几年自己可见的速度在记忆力下降, 每次看到 golang 面试题的帖子, 很多也是不会, 只剩下一些实践的套路经验了, 上年纪了也没体力重新读这些书了, 不是不想, 而是真的力不从心了
幸好工作上也不太需要这些概念了

华山派剑宗风清扬我做不到, 但是像他一样的风格还是适合工程实践的, 什么这个气那个气的内力之类的, 先能把工程搞定并且搞好才是好

早早入行, 未来可期, 加油加油!

@Kauruus
@CRVV

补充一点, 工作久了也不是钻研学术的, 很多概念定义也早忘光了, 我更多的是专注于实践, 所以有说的不对的地方是我不懂, 说错了我就认, 不会赖账的

另外, 就像我前面说的没必要咬文嚼字, 聊具体的代码问题, 不需要纠结严格定义的, 咱就少点学术氛围, 免得搞半天也搞不出个成果来

@ykrank

> 等你技术进步到和它“一个层次”了

你这个"它"很会用啊, 你技术强的话可以输出技术观点, 技术的观点一点没有, 有话都不敢直接说, 阴阳最有一套是吧?
你咋不上天呢?

@Kauruus #145

> “这组线程”就是内核线程，有对应内核调度实体，Goroutine 才是“用户态线程”。

在对线程的细分定义上讲, 用户线程你说的对, @CRVV 说的也对.
我之前没有深究过用户线程这个细分概念, 把它理解成非内核创建的线程了, 是我的错.

不论严格定义如何, 把 goroutine 叫成协程已经是大家的惯用叫法, 日常讨论说线程用于代表严格意义的内核线程多些, 除非涉及细分定义, 否则也不会去区分用户线程还是内核线程.
但是如果把 goroutine 叫成线程, 是更让人混淆的, 把 goroutine 叫成用户线程是严格定义上正确但在日常交流上更多也是会带来麻烦
各种细分的严格定义, 例如说线程的时候不叫线程而是叫轻量进程, 也是给非学术交流带来沟通障碍, 约定俗成的叫法可能会更适合日常讨论.

> 按照你的说法，就变成 M:N:O 三层了。

我只是想表达: 线程 -> go runtime -> goroutine, 没有想表达是几层, 具体到 goroutine 的调度就是 go runtime 的 GMP,

而且几层也得看怎么划分:
如果按照调度实体分类, 那就是两层: 线程被内核调度, goroutine 被 runtime GMP 调度
如果是按这些抽象角色分类, M/P/G 也可以说是三层