现在 FFM 已经很好了，底层库也不应该过多考虑用户交互层面的事情，可以看下 jextract ，我自己是觉得足够好用了。

我是经常收到招行的类似电话，忙着就直接挂掉，有空就让他在招行 app 上给我发消息。

你为啥把工资交了但是不把存款也转了，是不是不信任她在留退路？

@youngxxx 我倾向于是黑灰产通过某种方式把审核模型搞崩之后大面积上线违规内容。把模型搞崩的方式就不清楚了，有可能是内容投毒，也有可能是利用了某个 0day 。具体还得等官方或者快手内部调查的结论。你这个人工瓶颈的理论过于不合理，制度设计导致某个流程依赖某个单点的人，这个单点的人出车祸都比你这个合理。

使用 Java 的有没有用过 eclipsestore ，基本上可以实现 OP 说的这个效果

快手这次显然不是自动审核机制缺位导致人工过载，如果真的有人类介入，事情怎么可能搞到这个程度。

快手明显是过度依赖模型审核，导致模型雪崩之后后台失去了对线上内容的控制，甚至都没有及时报警让人介入。

快手这次是风控和运营策略的失败，和审核没什么关系。

@5261 不会。

golang 程序员经常吐槽的 spring/java 味通常是指冗长低效的逻辑嵌套，比如封装 Accessor Methods ，堆叠套用各种工厂模式，还有屁大点事都要 New 一个对象。
这些是代码里的坏味道，但这是程序员的问题，不是面向对象的问题，假如有人看到面向对象的东西，就说这是 java 味，那是这个人的问题，不是代码的问题。
使用 fx 这样的 DI 框架，你首先就需要接受面向对象这个编程范式，这是个好东西，绝对可以帮你们消除混乱的全局状态，管理好应用的生命周期。
如果你们团队里有比较好的 Java 积累，我估计你们大概率确实会在 golang 里复刻一些在 java 里很常见的设计模式，这可以说是 spring 味或者 java 味，我觉得不是坏事，用 golang 的语法大概率可以写出更地道的代码，但能被大家理解，能解决问题，足够稳定的代码就已经是好代码了。

@5261 我的观点是要用 golang 写上规模的微服务，是必须结合 k8s 的平台能力，这不是优点，是 golang 语言生态的缺失，当然这个路子很多公司在走，也很顺畅。

golang 还可以用来写单体服务，写客户端应用，甚至写游戏，这个语言绝对是一个设计优秀的语言，没有 k8s 也能用它做很多事情。

shell 执行 `open -n Your.app`。

既然你用 aerospace ，就直接绑定一个快捷键执行 `exec-and-forget <open -n Your.app>` 就挺好，Alfred 的 shell 环境变量不太好配。

@5261 那我就直接点，你列的这堆 AI 写的东西，不是 golang 和 java 语言的差异，更不是 golang 比 java 更优的地方，充其量是典型 Google 技术栈和典型 Spring 技术栈的差异，而且这段东西暗示的 golang 更优这件事情是不存在的。

你不是很懂 Kubernetes ？你列的 golang 这堆平台能力就没有哪了是能离得了 Kubernetes 的，你不懂 Kubernetes 咋用它们？就“云原生”“用平台”听起来很帅气？一点成本都没有的吗？

自己不懂 Kubernetes 也没有靠谱的运维团队帮你玩转这一套，就“用平台”，“移出代码”？
有运维提供平台能力，spring 这一套确实臃肿不堪，但是 Java 生态那么多框架，为啥指着 spring 的不足就要转 golang 呢？

---

golang 简洁无糖的语法，天然的协程支持，简洁好用的并发同步机制（ channel ），极小的运行时，某种程度上更优的跨平台能力这些东西你不夸，还你写的代码有这味，咋的你能把平台能力封装进 golang 的框架呗

重写的 hashCode/equals 方法应该是默认实现的上位替代，所以你的“在使用的过程中如果不知道这个类复写了 hashcode ，那么就容易导致代码问题”是不成立的。

而由于默认实现的天然缺陷（容易把两个逻辑同一的对象当作不同对象）——考虑经典面试题 Integer 池和`new String("")`——在可能作为 Map 的键或 Set 元素的场景中重写 hashCode/equals 是必要的，对于关键的数据对象（如包含 id 字段的 User 实体类），你无法预见它们的使用场景，因此当然应该重写。

我觉得这俩思路和语言关系不是很大。
golang 因为比较新，它出来的时候 Kubernetes 就是微服务的事实标准，服务网格也方兴未艾，所以很多工具直接就走这一套，其实现在用 golang 写的注册中心、配置中心也不老少。
Java/Spring 太古老了，几乎能在里面找到历史上所有微服务解决方案的影子，搞到今天这个地步，复杂度我觉得是已经到了离谱的程度，有识之士基本上都在另起炉灶（ micronaut quarkus helidon, etc ）。

对有靠谱运维且技术栈较新的团队，还是别用 spring 那套了。

没有具体需求很难说，比较通用的还是 web 技术生成页面然后转成 pdf ，面向打印机的话直接生成 LaTeX 然后用工具导出。

现在好像很少有笔记软件支持 diagram as code 比较好的，建议集成下 kroki 。

@SSang #6 你这个有点滑坡了，shell 、makefile 是用来管理环境的工具，IDE 也可以是呀，集成开发环境的本意就是把一堆复杂的配置集中化管理，减轻程序员的心智负担，shell script 和 makefile 其实也都是我们集成环境的一部分。

我认可环境配置应该与个体无关，任何开发者有权根据自己的偏好选择自己的开发工具，项目本身不应该阻止开发者发挥自己的创造力，但作为团队无疑是要在集体的取舍和个人的偏好之间取得一个最大公约数，在这个过程中，IDE 并不构成障碍（无论是 IDEA 还是 GoLand ，都会解析被广泛使用的构建工具链的配置文件 pom.xml/build.gradle/go.mod ），在这个层面 IDE 的差异就已经被抹平了。

我自己摸索下来的经验，是 Java 作为一个被最广泛使用的编程语言，涉及了无数领域，每种领域都有自己的特异性，而 Java 同时作为一个发展良好的编程语言，每一天都有新的工具出现，每六个月就会推出一批新的语法，要广泛覆盖所有的需求，并适配工具的发展，目前而言没有人比 JetBrains 这家商业公司做得好，eclipse 基金会不行，为爱发电的 Emacs/Vim 的扩展的开发者们也不行。实际上，我也用过 VSCode 的 Java 扩展包，VSCode 的开发者们无疑为它付出了很多的努力，在足够主流或者比较初级的用户需求上面，VSCode 已经超出了我的预料。

作为开发者，如果你对自由软件的喜爱超出了对效率的追求，那么花费一些精力去创造自己的开发环境，甚至反哺社区，我觉得是很好的一件事。如果只是浅尝辄止，那么不管是某款知名编辑器，还是免费或者社区版的 IDE ，我觉得应对偶尔的开发需求都够用。作为商业软件的开发者，我觉得没有理由在雇主愿意支付 IDEA 的费用的前提下，给自己找麻烦（其实大多数情况下社区版是完全够用的，现在社区版和商业版也已经合流了）。

把你的系统规范标准灌输给 AI ，它不能直接生成符合你要求的组件吗？

我花了一天时间配置 Emacs 来编辑我的 Java 项目（ Emacs 的 lsp-java 后端是和 VSCode 一样的 jdtls ），遇到了茫茫多问题，这套工具依赖 eclipse 基金会一串项目，大多数问题都需要这一串项目都做对应的修改，较古老的 issue 可以追溯到 16 年。

于是我明白了一件事：没有人不用 IDE 开发 Java 。

咋等于的？