@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 。

咋等于的？

devcontainer ？很难评。

刚需就买吧 当消费品买 不要考虑增值（不要当作投资去考量）

——刚需都是相对的，有时候想开了需求也就没那么刚了。

相模原创 001

一直再用 github copilot ，MCP/Agent 的操作就在命令行用 LLM 调其他的大模型，目前没有啥痛点。

我是迷你主机（ Intel NUC ）+硬盘盒+Unraid ，上面就跑了个 HA 、几个影片刮削服务，plex 和旁路由（ OpenWrt ），功耗很低，也比较稳定。

我在用云鲸逍遥 002 ，对下水道口的头发毫无办法，而且扫拖效率很低。

我和我老婆一开始在一起就异地现在修成正果，单程高铁五小时，一开始在一起我就每周一个来回。如果你有这样的觉悟，我觉得可以得到一个好的结果。