“单一时间线的即时通讯”其实不是完全不可以，很多社区都这么干，比如 ArchLinux CN 的群，各种 IRC ，甚至好像 Clojure 大半个社区都是在 Slack 上的
我觉得 IM 和其他形式并不冲突，这不是个 N 选 1 的问题

比如单纯的 Q&A ，可以使用类似 StackOverflow 的平台，把群里的问题引流过去。“微信群里十几条”不是完全没有意义的，对同一个问题，不同的人可能有不同的看法和不同的角度。尤其是 Blender 不 是 微 信（也不是 Python （狗头）），这些专业 DCC 都是非常灵活的东西，同一个问题的正确答案往往不唯一。而很多 YouTube 教程只能给出单一角度的答案，并且往往整上好几分钟，其中一半还是 Logistics ... 反倒是 IM 的即时性很容易激发“just-in-time”的讨论，大家会发出很多小的有意思的点，这是 IM 的优点也是缺点，比如这也导致了“非线性”的问题，但只要没碰到这类问题，效率是很高的。

说到这个“非线性”问题，用类似 BBS 的平台是无法解决的，因为 BBS 的主题虽然有更多的 context ，但是依然具有很强的时效性，所以还是类似 StackOverflow 、知乎之类的问答平台更合适。

你说的什么看不到历史消息，图片已过期之类的问题，更多的是微信这个 IM 特定的问题。但是作为一个 IM 重度用户，我的经验是所有 IM 在本身的功能和体验上都有很大的提升空间（低情商：每一坨屎都有独特的风味），从一个 IM 换到另一个 IM ，只是从一坨屎换到另一坨屎。特别地，我发现我使用的这些 IM 在历史消息的处理上都非常敷衍，没有一个 IM 能高效地搜索和备份历史消息——这方面反倒是 IRC 优势最大，中心化的 IM 会以把用户当傻逼为 prime directive ，试图接管用户的一切操作，导致用户必须完全依赖 IM 提供的服务处理历史消息，这才是万恶之源。

所以如果要用 IM ，可以考虑通过一些手段规避掉这个限制，同时还需要考虑如何把 IM 中的信息沉淀下来，减轻对历史消息的依赖。我觉得你学弟这个想法让人觉得别扭的根本就是这个——一个微信群可以用来“交流”，但它不是“社区”，社区是需要有内容积累的，而一般 IM 的消息，设计上是你想不看就可以不看的，没办法形成“积累”，所以不是不能用 IM ，而是不能完全依赖于 IM 。但是具体做成什么样还是要看你学弟的心理定位，毕竟纯粹意义的“交流群”也有一堆。

巧了，我之前是 HHKB 用户，现在是 NIZ 用户，为啥换了呢，就是因为 HHKB 进水坏了

@wcsjtu 还是那句话，非常依赖于具体的细节
比如“可以把 Python 看做静态语言”这一条，假设有 y = foo(x)，在静态类型语言中，foo 一般有一个预定义的类型，比如需要一个 int 并返回一个 int ，这时如果 x 原本是个 float ，调用 foo 时会被 coerce 成 int ，但是在动态类型语言中，x 传进去之后依然是个 float ，并且可能在 foo 内一直以 float 的形式参与计算。自然就可以推出，在两种语言中实现并调用逻辑类似的 foo 函数，得到的 y 可能是不同的值。这两种情况的类型推导的处理方式也不一样。
再比如“类型标注”这一条，如果可以做到所有的函数和函数参数、返回值以及 class 的成员都有类型标注，问题会 trivial 很多，因为这样就和普通的静态类型语言没啥区别了，甚至大多数情况下都不需要怎么“类型推导”，而只需要按程序顺序根据类型标注给出的信息 check 一下函数的形参和实参类型是否匹配，需要“推导”的主要是泛型参数和 lambda ，问题的规模一般都比较小。
但是如果项目的目的是兼容一些已有的 Python 代码，那上面这两条都会有坑，所以我之前的看法一直都比较保守。

目前最简单的答案就是无脑 Unity ，除了更偏商业化之外，Unity 就是游戏引擎中的 Python 。
放在十五年前这个答案可能是 Flash ，可惜啊 ... 现在简单点的话用 Web 也可以

而且我很纳闷为啥学了游戏设计和游戏引擎，却不熟编程，难道没写过小游戏 demo ，学游戏引擎只是像我一样学学概念纸上谈兵没摸过代码？

你买了么玩了么？

另外表明一下我个人的立场，对于我个人来说，Hybrid 和 Disaggregation 都是卖点——因为我自己没事会研究下 CPU 架构之类的东西，Hybrid 就像那句话：“两件快乐事情重合在一起。而这两份快乐，又给我带来更多的快乐 ...”
其实我觉得程序员应该是乐见这些花活的，整得越多，程序员发挥的空间就越大。现在“寒气”都不算啥，哪天真人人都能无限算力+ AI 编程了，对于程序员来说才是绝对零度。

桌面这里 Hybrid 和 Disaggregation 解决的都是同一个问题，并且是对于这个市场来说很重要的问题，就是成本问题。
同样的多核性能（就 general purpose compute 来说），做多个 die 比做单个 die 更便宜，多用小核比多用大核更便宜。这俩本来就不冲突。所以最后两家给出了一样的答案——我都要，Intel 在 MTL 和 SPR 也要搞 Disaggregation ，AMD 在桌面要不要搞 Hybrid 不知道，但是如果他们想搞但现在还没搞的话，楼主说的问题大概是一个重要的原因，所以他们干脆就“先”不搞。

注意是“先”不搞，https://www.pcgamer.com/amd-ryzen-hybrid-architecture-big-little-intel-alder-lake Intel's pinning its future on Alder Lake's hybrid design, but AMD won't follow suit 'just to have a bigger number 这个 AMD 高管的言论很多网站都在报道，但是 PC GAMER 报道得最好，因为他帮你划好了重点“Just driving up the core count with little isn't going to be that useful until software comes along”——也就是说 AMD 不做软件上的脏活（可能是被推土机整怕了），那谁来做呢？纯软件开发者肯定不做，所有硬件都是一样的核心干嘛要做；硬件厂商再都像你 AMD 这样，那就永远别做了？
这个言论虽然是两年前的，但是在这个十月再来看尤其有趣，因为相同的事情其实刚刚就在 AVX-512 上发生了。

还有人说为啥服务器不 Hybrid 。其实 Hybrid 是 Intel 全局的一个方向，服务器也有对应的产品计划 SRF ，这个和 AMD 的路线其实更像。那为啥不把两种核心放一个 package 上呢？当然是因为这个市场的客户都知道自己要啥，HPC 的就买内存性能高的就行，要功能全高性能就买传统线，云厂就买小核，跑什么东西就买什么机器。也就是桌面这群**，既要单核性能，又要多核性能，还要便宜，怎么不去咬打火机呢

实际上 13900 的 die size 已经非常接近同产品线历史上最大的 11900 ，而考虑到后者本来就是不太正常的过渡产品，想像一下同样的多核性能全用 P 核实现是什么画面 ... （当然另一方面是目前 Intel 的 P 核效率有点问题） CHH 不懂尚且“可以理解”，毕竟“CHH 那里的水平”实际上就是连贴吧和微博都不如的水平。V2EX 作为一个程序员为主的社区，如果也不懂工程中 trade-off 的意义，我就不得不开始怀疑“V2EX 这里的水平”了。

#13 说的倒是比较中肯，杀死 HEDT 这事简直可以算是“U 界”的“4080 12GB”。我前段时间做的一个东西放 MSDT 的双通道 DDR4 上，别说什么 24C32T 了，跑仨核心就把内存带宽跑满了，再加核心一点用没有。

强迫自己每天 14 点 53 分落一次泪

Linux 下面 nvidia-smi 那个 GPU Memory Usage 不是 N/A ，是能显示出数据的。
比如我这 Steam 就占了 1GB 多，桌面占 350M 不到。

我觉得是时候学习直接输入 Unicode 码点了（狗头

“小”是和什么比？

@wcsjtu
这些问题的答案其实严重依赖于你做的东西的具体需求和设计
比如准确来说隐式转换也算 subtyping ，但是动态类型语言好像不存在这方面的问题，虽然如果你要性能非要用 unboxed native 的值表示那这个又必须要解决
因为在运行之前动态类型语言其实是不存在一个确切的“类型”的。比如 def foo x = x + 1 ，x 是个 int ，那它此时就是个 int -> int ，x 是个 bool ，那它又是 bool -> int ，这个和传统 HM 那套是不一样的。单就这段程序来说，typechecker 得到的信息只有“若 x 的类型为 a ，存在函数 +: a -> int -> b”，然后你要做的就是想办法把这个信息记录下来，Typeclass 和 Row Polymorphism 之类的其实就是信息的表示方法。

更 general 地说，基于 HM 可以延伸出一个更通用的框架，typechecker 会把 AST 转换成 constraint 的集合，然后再去求解这些 constraint 。HM 的 constraint 非常简单所以好解，但是如果把丰富下语义是可以解决更复杂的问题的，当然可能会比较慢，很多较新的静态类型语言都用了类似的思想，比如：
https://github.com/apple/swift/blob/main/docs/TypeChecker.md
https://kotlinlang.org/spec/type-inference.html
https://rustc-dev-guide.rust-lang.org/type-inference.html

不过这些都是静态类型语言的玩法，我暂时无法想像这种东西怎么在动态类型语言上 scale ... 其实动态类型语言用的好像都是不太一样的方法，我主要折腾静态类型语言所以不太熟悉。

HM 是常用的算法但不是唯一的。HM 的特点倒是非常明显，标准的 HM 可以在没有任何 type annotation 的情况下推导出一整个程序的 principal type 并且对于大多数实际程序都很快。但是这是类型系统本身做了一些妥协的前提下的（其实 HM 这词本来是指这个类型系统不是推倒算法，那算法叫 Algorithm W ）。

先不说什么 higher-ranked type 的问题，在 ML 等基于 HM 的语言中，取列表 x 的第 y 项需要写成 List.nth x y ，其实这里面这个“List”（准确来说是 List.nth 这个函数的类型）已经告诉算法 x 是某种 list ，y 是个 int 。而如果（以 Python 为例）算法只能拿到一个 x[y]，是无法分辨 x 到底是个 list ，还是 tuple ，dict 的，y 的类型也无从确定。再比如说定义俩 struct （虽然 FP 圈一般习惯叫 record ）分别叫天猫和京东，每个 struct 有个字段叫双十一，然后 def foo x = x.双十一，x 的类型就喜闻乐见二选一了。这就是为啥 HM 只在部分 FP 语言里吃得开，毕竟大多数常用编程语言都是按照后者的思路设计的，再来点 subtyping 直接跪。

我的意思是这东西上限也就那样，毕竟就算 FP 语言类型系统沾点高级特性也基本是用不了 HM 的。当然你这个比较简单拿 HM 来魔改一通大概是勉强能行的，我上面提的问题用 Typeclass ，Row Polymorphism 之类常见扩展也都能解决，不过可能会搞得实现和类型签名稍微复杂一点。不过检查个正确性貌似也并不需要 care 类型签名 ...

不仅不同国家的发音，英国不同地方的发音都能区分 ...

问题是你就算搜遍你的某鱼，除了 4090 自己之外没有任何其他一张卡能和这玩意比性能啊 ... 这就是定价的底气，你几百块的矿渣性价比是高，但是不能*替代* 4090 。除非你能魔改游戏改出多卡优化来

相比之下那个被“Unlaunch”的才是真的呃呃

我是 2K+4K ，现在用 Sway ，总体来说大问题没有，小问题不少，不建议尝试
这上面 Wayland 是个坑，NVIDIA 也是个坑，然后 fractional scaling 还是个坑
最近正在手动折腾 fractional scaling ...