两人都是大神, 各有对错, linus 的立场是非常正确的, 项目中有这种路线冲突之类的问题很正常, 应该沟通寻求各方都能接受的方案.
项目内的事情没必要发作文, 他们两个争论什么其实不是重点, 写作文才是导致问题爆发的点, 写作文才是真的搞政治的魔怔行为, 完全意识不到自己的问题而且随便去发作文说明他本身就心智不咋地.
强烈支持 linus !

对于 rust, 至少我见到的有足够基础的人都是赞美, 几乎没有人贬损 rust, 最多就是觉得它难度大不好学.
反 go 的那帮人的言论, 才是真的魔怔.

300%也还是慢...

踏踏实实的技术帖, 比隔壁凭借哪些特质走到现在可是赞太多了

@sthwrong @kekeabab #24 #25 没什么好办法, 又何止是工作, 程序员至少还是逻辑比较强的, 生活中的更多人和事情比这还折腾. 改变不了, 气也没用, 不如平和, 效果反倒会好些. 应该庆幸的是自己不是这种, 自己已经是极少数的优秀了, 如果心态能平和, 自己会更厉害.

@lujiaxing #8 绝大多数都是普通人. 会用梯子和懂你说的那些也并不能代表牛逼, 老外很多你说的这种"菜鸟", 对这些人而言, 写代码这只是一份工作, 他们挣钱享受生活, 很多这种人家里条件都还可以, 他们自己没生活和钱的压力所以不需要卷技术. 除了具体技术问题要争对错, 怎样的技术追求和技术节奏, 并没有什么必要去批评. 我年轻时候也跟你一样, 眼里看着很多菜鸡老司机程序员啥也不会, 心里也很鄙视, 直到闲聊发现, 比如一个同事, 刚毕业工作家里就给买了 180 平的房子奥迪宝马两个车换着开后来老被同事议论觉得太高调了不好又买了个便宜车用来上班开, 比如另一个同事不只是啥也不会而且还很笨他自己倒是挺想学技术的但学很慢甚至学不会, 但是他家深圳开农家乐而且那半个山是他家的.
做自己喜欢的事, 让自己活得幸福, 珍惜自己重视的人, 其他的, 不那么重要

先问问其余那 99w 是不是他们自有资金吧, 万一大头都是借的需要好好劝劝他们更谨慎点, 毕竟亲姐姐, 除了考虑借不借也得多关心关心

回 LV 好些

应该增加锻炼身体的时间, 运动能让状态心情大大提升并且预防电子产品相关的慢性疾病

@mingtdlb #27 刚开始那段时间好像站长有发公告帖子禁止这个, 但很多人没看到; 创建新主题有提示, 但是回帖的时候没有这个提示. 所以, 很多人可能仍然并不知道有这个规定. 很多人被封时一脸懵逼, 被封了才知道有这个规定但为时已晚

@PROJECT #18

@Livid 建议把不允许直接使用 AI 回复的指引做更明显些, 有不少用户可能并不知道有这个规定, 甚至是老用户. 或者, 第一次封禁一周, 第二次再永久封禁, 人非圣贤, 何况不知

@guanzhangzhang #46

> 你这些的前提都是 server 和 client 都是自己写

这不废话吗. 如果是涉及已有的或者别人的, 你自己没法自己搞的, 当然得用已有的啊, 或者改造成新的. 你都有现在的限制了而且不想改造, 为什么还要来问其他的方案? 这不是浪费别人时间吗?

感觉你自己对技术不是太懂, 所以你不明白具体问题在哪里, 你问问题的时候也难把问题描述清楚. 如果不是不懂技术, 那就是纯伸手党了. 不管哪种, 建议不要白白浪费自己和别人时间, 问问题之前至少自己先搞明白一些基础, 这也是对别人的尊重

@picone
就目前国内开源社区的 go 游戏框架的玩具看, 我的 arpc 随便封装点日志/串行化的协程池就可以叫游戏框架了...太没含金量了, 都不好意思这样叫

还有些重度的, 好像 nano 是沿袭了网易那个 nodejs 的 pomelo, 这种定位重度 mmorpg 类业务的框架他们真是真敢做, 而且都是直接选择不适合的语言, 用 node 是错, 换到 go 赛道继续错, 作者是想为社区做出多大贡献猜不透, 但公司内 KPI 升职加薪的作用应该更实事求是. pemelo 当年做的早, 随着手游行业爆发, 吸引(骗)来了不少小白.

那年代的游戏团队, 不只是 go 的在摸索, 整个行业团队里, 多数都是技术不合格的. 因为原本没那么多游戏公司/团队/项目, 而是随着智能手机的发展, 大概 2012 国内一些团队创业成功, 开启了游戏创业潮, 然后大量资金人员涌入. 本来没那么多游戏行业的人才, 资金/项目突然爆发增长, 对应的人力也爆发增长, 不只是技术的人, 制作人/策划/美术, 都缺人, 大量成立的团队里的人力, 只能是拔苗助长的方式, 良莠不齐, 弱鸡居多.
游戏行业不像 web 领域那样, 不同公司不同业务不同规模, 但主要的通用的基础设施都是 web 前后端数据库之类的这些, 社区范围更大, 不管哪种语言也都用这套, 所以 web 领域的整体社区技术比较容易一脉下来形成不同的子派别, 卷这些的社区领袖人多水平也不错, 就容易弄得工程. 游戏则不同, 不论公司大中小, 几乎每家一套自己的, 这其中很多所谓的主程自己不具备开发底层和框架的能力, 就拿着以前公司师傅师爷的祖传代码拿来稍微改改.

而且当年好像真有脑残的大项目技术负责人拎不清, 用 go 做大型 mmorpg, 完全没考虑过 gc 甚至都没做个像样的压测, 一开服压力上来了就卡得不要不要的, 这种挖大坑很难有机会去优化, 线上运营口碑凉了项目直接就凉了

> 江湖不是技术来技术去 是打打杀杀 人情世故 天变了

@ugpu 其实除了元素数量太时 gc 的 cpu 压力, 以及其他类型的强 cpu 压力类的项目, go 还真是都能做. 街篮那种非重度 fps+类 moba 的, 房间人数不多, 也没有农药那种满地图建筑/怪物/兵之类的各种压力, 用 go 都绰绰有余. 那些中小游戏甚至便单机的游戏就更不在话下了. 所以很多团队用 go 是非常合理的技术选型, 跟人情世故没啥关系, 不用这么委屈自己

@librasolo #36

leaf 看上去甚至比 zinx 还差一些, 可能 zinx 毕竟要做课程所以毕竟略带着点"学院派"的工整. leaf 的年代更早点, 那时候 go 社区里轮子少, 国内 go 社区也非常活跃, 论坛和技术群都大把人, 随便写点什么宣传下, star 就上来了.
但那个年代的玩具项目多. 游戏行业的 go 服务端更是属于很多团队在摸索中的状态, 不能怪社区水平, 而是历史局限性

@shellus #32
能对框架选型发问的用户, 绝大部分人不是用来做大型游戏, 这类需求的主要部分其实就是个网络库. 性能需求不大, golang 足够, 而且相比于 c++或者 rust, 开发效率爽死

真要是做大型游戏, 基本都自家团队内解决选型和研发问题了, 自家负责技术的人如果连框架架构的能力都没有的话还做毛的大型游戏, 如果大项目还要外面咨询选型的说明这项目从立项就凉了 80%了, 除非中间把技术的人换掉

@guanzhangzhang #33

Call 是请求需要对方响应, Notify 是只发消息不需要对方响应, Call 是同步的, CallAsync 是异步的.
client/server 两端都可以主动发起 Call/Notify.
arpc 是涵盖了传统游戏服务器网络库和 rpc 模式的, 所以支持的业务场景更广更好用.

要不你先看下 arpc 的例子吧, 有提问这功夫, 花几分钟看下 Readme 早就懂了都可以开始写逻辑了:
https://github.com/lesismal/arpc?tab=readme-ov-file#quick-start

@guanzhangzhang #29

如果你们客户端使用的引擎语言支持标准 js, 可以试试用 arpc, 处理你说的"同步"这种问题, 比 msgHandler 简单方便多了.

@guanzhangzhang #29

客户端的交互, 绝大多数项目, 本质上都是异步的.
因为客户端发消息基本上是在 eventloop 主线程触发的, 如果不是异步那就要卡渲染了, 客户端引擎的 eventloop 线程里的操作不应该有阻塞. 除非有特定需求是不需要主线程逻辑触发, 才可以考虑异步线程去同步 IO 的模式, 不影响 eventloop 主线程就行.

如果想"同步"代码, 要依赖不同的游戏引擎, 或者说, 主要是依赖你编写这部分逻辑使用的语言以及这个语言对"同步"支持的程度.
这里说的"同步"不是指同步 IO, 而是指类似协程这些让代码顺序看上去同步的语言特性. 比如 lua 可以用协程, js 可以用 Promise 甚至 async await? 一些引擎自带的语言并非标准语言而是变体, 那么则要看这些具体语言的特性了.

传统的游戏客户端服务端网络协议主要是命令号, 命令号对应 handler, 但每个 msg 和可能收到的响应不方便一一对应, 所以即使是协程/Promise 之类的看上去"同步"代码, 传统游戏协议也不方便把发送的 msg 和响应对应起来做这个同步.

arpc 的 js client 是默认支持了 Promise, 并且本身是通过 rpc 的方式实现的协议, 每个 call 都与响应一一对应, 所以可以这样用, 这样看上去就比较方便了:
https://github.com/lesismal/arpc/blob/master/examples/webchat/chat.html#L81

@asuraa 再补充一下, nginx 的多进程也有不均衡的问题, 比如很多连接均匀连到不同的 worker 进程上, 但是很多断开了, 剩下的大量连接分布在少量 worker 进程上, 仍然是不均衡的.