@namonai #57
所以到现在你还是觉得 “也就是个 message”、“只是支持而已”。

如果自己只在第一层，看不到第五层拒绝的原因很正常、可以理解。但是二三四五层的好些人出来解释了好多次了都不看、这属于是自己强行用自己在第一层的视角去黑第五层。
那没什么可聊的了

> 背景：我们是一个 Java 系统，使用的是 xxljob ，最近使用 go 重构。

刚才没仔细看，以为是要再造个 go 版的 xxljob 。但是不影响#11 #12 总体观点，补充：不只支持 Gopher 造轮子，也支持适合的项目用 go 重构！尤其那些内存怪，尤其那些换 go 重构之后硬件占用大幅降低的！

强烈支持 Gopher 造轮子，能造好皆大欢喜、社区基础设施越来越丰富，即使造不好就当学习练手了、而且造不好大家不用就是了也没什么损失。
先不说 CTO 是不是装逼，就从这个层面支持团队造轮子我就先支持一票！业余时间为爱发电精力有限太辛苦，有这种支持带薪造轮子是多好的事情啊！很多人羡慕还来不及呢！

> 大道至简
> 全靠手搓

@tongbufu #3

java 1995 年诞生之初就啥都有吗？一个语言的基础设施和生态是无数开发者手搓出来的，虽然不需要 curd 自己手搓、但也需要时间发展，go 还很年轻，如果能有团队站出来添砖加瓦，至少我觉得是好事情。
OP 家的 CTO 让 OP 他们做 go 版本的两面看：
1. 如果团队能力 ok 能做好那是好事情、如果开源我去 star ；
2. 如果团队实力不足以做好那是 CTO 自己装逼了。
现在只是开头，不了解 OP 团队实力、没看到过程和结果，我不妄加评论，但是希望 OP 加油，这是个提升自己的好机会。

有人可能反驳、xxljob 现成的来为啥要重复造轮子、没必要 go 或者 rust 手搓，那请自己看看 java 的这些被大家用来重复造轮子的原版和新轮子的性能、硬件开销的对比去吧，但凡如果只提升了 5%那这种重复轮子都是浪费时间，但很可惜、每个新的好轮子都不只是这点提升。
另外，很多中小团队，希望避免过多技术栈的引入来保持精简干净，go 的部署也更容易，相比于还要先学习研究下 java 环境各种，如果有 go 自己的轮子，go 开发自己把 devops 的活也干得更轻松开心些。

大道至简从来不是个坏事情，不喜欢的人不懂得把工程搞扎实、但喜欢的人多了去了。
就说 v 站吧，你看看 go 的帖子频率怎样？你门以为越骂越火是因为被骂火的、像娱乐圈一样吗？
很显然不是，而是因为很多喜欢 go 的人不善于归纳总结和反驳因为这需要理中客和技术深度、这样的文字更具难度，这些人在踏踏实实用 go 做事发声少罢了。
但相比之下，嘲讽起哄非常容易、加之跟风的心理学作祟，所以显得骂声很多罢了。
喜欢的人越来越多，所以 go 的份额也在增长和企稳，骂 go 的声音就类似于幸存者偏差。

自己不给社区添砖加瓦没关系因为这从来不是必须，如果能输出好的技术观点骂到点子上那也是好的技术交流，但如果只是无脑嘲讽，并不能抬高自己，一点都不高尚。

> 语言和语言特性在我这里大概没这么重要，考察的是计算机基础。

如果是不需要编码的题，你这样说没啥问题，说思路就行了。但你这个题目是“手写一个函数”，编码了，用什么语言本身就是很大问题了，比如用 c ？。。。

> 需求不明确可以沟通，也看看沟通能力。上来只会喷的，大概是做题做的思维固化了。

看你的题面，这种多是笔试题。即使面试题，也可以，而且别人也没说不沟通啊。

但是这种简单问题，还要这么歧义，我只能认为是被我上一层回复后强行挽尊找的理由罢了。

更何况，这是论坛，你发个这种题目出来指望大伙楼下挨个继续追问题目，浪费大家时间呢么？。。

BTW ，我已经很多年没做过题了，我也从来不出这种题目去浪费别人时间。

年轻时候遇到过很多笔试题面试题题目本身就 sb 的，我也以为是故意考察沟通能力，所以也都沟通过，沟通之后发现，绝大多数这种题目吧，就是出题人自己拎不清。甚至一些语言的语法题，还得面试现场我教他。
更逗比的一些中小公司，自己工程里遇到的问题搞不定，拿来当面试题，我曾经就遇到过这种、然后面试时候解决方案优化方案一顿输出，给他们讲了一个多小时，面试官做笔记很细致。。。虽然这种我也不会去，但是技术交流也无所谓被他们白嫖，何况他们态度还恭敬的。。。


> 上来只会喷的

上一楼我只是比较平和指出你的题目的问题，我自己并不觉得是喷，为了避免让 OP 以为是喷，所以我用了“恕我冒昧”。

OP 也不必太敏感，上来就否定我指出的实际问题。
至于思维固化，这种题目用十年，是不是也该反思下到底是谁固化。

题目挺不错的！
答案挺解压的！

生活就是应该这个样子！

隔壁 /t/1121006 题目没什么歧义、简单算法也算实用常用。
OP 这个题，恕我冒昧，这是近期看到的最垃圾的面试题，竟然还用了十年。
BTW ，近期一共看了两道面试题，隔壁和这里。。。

最基本的，没有标明语言，不同语言静态动态强弱类型对 map 的处理可是不大相同的，是否只是处理数值类型的 100 ，不同语言对类型的处理也是不大相同的，搞不好还要反射

> 输出要求把其中的数字 100 替换为数字 200

这句，不算严谨，字符串里的数字 100 算不算？反正我是不能确定出题者目的
如果是说 数值类型的 100 ，就不会太歧义了

> @lesismal #24 好吧，我表达的有问题，不是说随便接受 pr 。开源项目的一大优势不就是可以倾听社区的声音吗？我意思是没必要这样毫无余地的就拒绝，如果社区呼声很高，也是可以考虑的吧。

基础知识储量不够但是又有兴趣的话，可以多学下，等理解不到 pb 的设计、实现、原理、做这种更改尤其是是多语言的难度和影响，你大概就不会再使用 “也就是个 message”、“只是支持而已” 这些轻浮的话了，技术的问题最好是能让自己有理有据的输出、而不是“妄加评论”

相比于社会、生活中的很多事情，技术更严谨，无知者无畏、我穷我嗓门大我有理这种发声方式不是好的方法，你想想，自己不占理还要喷别人，跟那些非法医闹、水军舆论绑架有什么区别？

“倾听社区的声音” 和 “倾听社区正确的声音” 是两码事。如果不懂，至少就请尊重和慎言，而不是诋毁。

越读书越学习越觉得自己无知，共勉！

> 而且我觉得最恶心的一点是他们不仅不愿意支持这功能，而且还不愿意接受外部设计，连提 pr 的机会都不给。

别人合理拒绝，却反过来说别人封闭，什么道理！
要都是随便接受外部设计和 pr ，各种项目早都得被乌合之众搞凉了！

开发不要买 mba 和 14 寸 mbp ，这俩都烫手，只有 16 寸是正途

我个人对这个面试双方的评价，不一定对：
1. OP 的编码主要是应用层，对基础知识不那么深入；
2. 面试官是杠精；

面试这种问题、如果候选人的回答已经反映出了 1 ，就没有必要像 2 这样纠结基础知识了：
1. 如果是招来做系统工程师之类的基础设施、底层研发，直接 pass 不考虑了，没必要继续杠
2. 如果是做 curd 之类的业务开发，了解这些基础知识也没用、只需要用来判定技术深度和技术等级、薪资就可以了，也没必要继续杠

> thread 和 coroutine 最大的区别就是上下文切换是否自主可控。因为 thread 切换不可控，所以要应付数据一致性的地方比 coroutine 多得多。

@moudy #51 我感觉这没说到点子上，绝大多数应用层自己主动使用 go runtime.Gosched 也只是出让调度、业务逻辑本身并没有改变、runtime 调度回来后用户的逻辑代码还是那个执行顺序。

我觉得根本的点是 thread 、goroutine 的成本和数量、以及对应着是否需要用户主动操作实例（例如 conn ）在多个 thread 或者多个 goroutine 之间的切换。

高在线业务，不可能为每个 conn 都创建一个 thread ，所以每个 conn 是在不同的 thread 中流转，比如处理网络的 io 线程池、cpu 消耗的 逻辑/worker 线程/线程池、数据库等其他基础设施的线程池，不同的线程池上下游之间要有 task 队列串联起来。用 thread 的语言和方案的框架封装和使用上更复杂，而且不能写同步代码。async await yield resume 那些手动档 coroutine 和 goroutine 、erlang 进程的自动挡是不一样的、远不如自动档方便。goroutine 和 erlang 进程轻量，每个连接一个、同步代码一把梭就完事了。
thread 方案对一致性的要求更高，goroutine/erlang 进程除非涉及连接之间的复杂交互之类的、否则不需要对一致性做太多麻烦的事情

妹子换男友都没 OP 耳朵这么矫情，放轻松，多用几次就适应新的形状了

明前龙井马上要出货了，如果不是本来就身体虚、多喝点，其他绿茶也都好，清热利尿降尿酸血脂，还不怕吃错了药副作用

45678 ，每年最香的几个月，得好好喝个爽

引入多点的设计模式，只要能沾边的就弄成设计模式，然后就一坨坨的了。
如果你水平高、能把设计模式用得如鱼得水、那么就可以轻松搞出很多没必要甚至不合理的设计模式的垃圾代码，就更难理解，至少阅读代码层层嵌套就增加了理解障碍。

好处是可以用来作为自己代码的理由，别人没法拿这个当作你恶意代码的证据；
坏处是别人可能拿这种代码当 sb 、以能力为由干你。。。

我自己至今没学会设计模式，所以看到设计模式重的代码直接脑袋宕机变 sb ，但一直钦佩能把设计模式搞得精通的大神们

atomic.AddUint64 1ns 级别的，1s 百万也没什么压力的，shards slots 的计算量比简单 atomic 浪费的 cpu 多多了，我觉得是多余的设计。
如果需要保存一段时间内数据、就用 len=时长/interval ，[len]uint64 ，起个协程每个 interval 更新下 index=(index+1)%numSlots ，qps 的地方 atomic.AddUint64(&slots[index], 1)就可以了，没必要搞那么多有锁无锁的炫技，脱离实际的炫技会带来负优化

> 大部分人是能够做到根据实际情况做出技术栈的选择的。但是问题在于一部分用语言圣战掩盖自身无知和懒惰的人发出了巨大的噪音。
> 这部分人无限拥护自己所支持的语言的目的不是为了使某个项目变得更好，而是为了通过语言斗兽棋强行体现自身优越。

我不知道这是不是你工作中同事在做的事情，我觉得大概分两种：
1. 那些业务量用原语言没有瓶颈的且有大量历史包袱的，没必要换语言去重构的项目，被很多人鼓吹换技术栈重构
2. 但一些明星企业搞了大量的 golang 重构也是属于刚需：性能的刚需和成本的刚需。很多 curd 的人不喜欢，但重构确实带来了很大提升

如果是因为 1 让你不爽，那确实是倒霉，但不应该根据 1 去否定 2 ，也没必要去否定某个或者某些语言的社区，真理掌握在少数人手中的情况很多，一个好的语言火起来、很多无脑拥趸跟风的人会来污染这个事物、但他们不一定是社区主流、也不应该成为社区主流，所以我个人和很多同行也是不喜欢看到很多其他语言涌入到 go 里然后用其他语言的方式去搞 go 。

> 内存安全的 rust 是很好，但是如果没有在延迟上有特定的要求，我可能更倾向于支持 GC 的语言。

强推内存安全不只是强推 rust ，java 、go 也都在推的，可能是因为 rust 自己更加突出地标榜自己的内存安全，所以很多人误以为推动内存安全就是推 rust 。性能和安全都要求特别高并且性能要求极致的 rust 是最佳，否则 rust 的开发效率也是感人、没必要。


> GO 无脑堆逻辑确实快，但是占一多半的 if err != nil return nil,errr 也确实碍眼。

这个怎么说呢，如果不是 go 这么要求，go 代码可能也不会这么健壮。

如果仅以所谓代码行数少带来的简洁性作为审美、并且用审美大于实用的标准要求自己的代码，那应该搞艺术，而不是做工程。你也提到根据实际情况做出技术栈的选择，这是务实的观点，务实不只是选择用什么，怎么用也是务实的一部分，毕竟如果不喜欢，大可以 “_” 忽略 err 和处理、可以不用去写 if err else 。

> 语言的特性是一个事实，没有一个功能或语法就是没有。至于是否属于功能缺失，我觉得判断标准确实要落在是否影响实际工程应用上。

至少我没有遇到过因为缺少其他语言的高级特性导致工程效率低，确实有一些小的麻烦，比如 err 处理的行数多些，以往用标准库 raw sql 循环 scan 麻烦些，甚至以前没有范型、要为不同类型都写几个相同实现，但这些多数归属于简单的逻辑、稍微花点时间就可以搞定了，并没有真正消耗开发效率。

> 我最多只能说：在我遇到的某个特定场景下，使用某些语言/工具是合适的。但是绝对无法断言，这些语言/工具能满足任意场景的需要。

@CapNemo 我好像从没见过 gopher 和 ruster 去鼓吹任何项目都用 go 或者 rust 去做，至少不是这两个语言社区的主流意志。所以，很迷惑，经常无法理解为什么会有这么多人得出这种结论然后给 go 和 rust 扣上这种帽子。


> 在我看来，不管是将 GO 的"功能缺失"强行解释为"哲学优越性"，还是以内存安全为由在各种项目上强行推广 rust ，这些行为都属于忽略实际条件去强行套用解决方法，本质上是编程领域的唯心主义。这种工具崇拜不仅引发争论污染公共讨论空间，也无助于提高自身水平。

没人强行推广 rust 去做 curd ，而且一些强行推广的行为已经上升到 us 政府行为，这种强行是基于安全问题日益恶化并且内存安全问题占的比例非常大、c/cpp 又无法解决这个问题。如果只考虑自己 curd 舒服，那当然无法 get 到这种强行对世界的意义，但这世界不只是为了我们 curd 服务的，而是反过来、curd 是为这个世界服务的，不要拎不清。

> 必须认识到，编程的价值在于解决实际问题。脱离工程背景无限拔高某些设计取舍只能暴露自身视野之狭隘。
保持对技术本质的清醒认知，才能在快速迭代的生态系统中构建可持续的工程能力。

这就更逗了，别人用语言是为了做工程，然后被一些用语言缺少语言自己的功能/特性扣帽子。
我就好奇了，你们那么多人都是在做开发编程语言的工作吗？所以某个语言没有某个或者某些语言特性就是“功能缺失”了？人家做工程好好的、人家语言现有特性能够做工程，怎么就功能缺失了？

为什么这么多人基础逻辑都搞不懂还要对别人务实做事的指手画脚。