@lesismal 我似乎并没有鄙视 Go 这种 panic 即退出的设计，我只是说下这个设计在没有结构化并发时几乎是必然的，不知道你在激动什么……

Go 的 goroutine 本身设计我不认为太大问题，但它的暴露形式就值得商榷了。难以直接被使用的 "go" 变成了关键字，errgroup 这种东西反而变成了 x 库。
“标准库没有就值得一喷”，标准库什么都半残那还叫什么标准库？我也没说标准库必须要带一套结构化并发，毕竟 go 出现的相对来说还是比较早的，但是 go 关键字的存在，除了更好打广告外，几乎看不到什么必要性。

Go 中 goroutine 未捕获 panic 导致整个程序退出这是在这个整体设计下的一个必然，Java 的 Thread 不这么设计，它并不鼓励程序甚至是业务代码中动不动就开一个 Thread ； Kotlin 的 coroutine 不这么设计，是因为人家有结构化并发，君不见 Java 绿色线程出来后马上也在讨论结构化并发的问题了。
Go 这边不搞这个，那如果 goroutine 在发生例外时不 crash 整个程序，可能就是个维护灾难了。

Java 的 try catch 和受检异常怎么说呢想法是好的，但标准库中的类型划分个人认为有待提高，太多该被归于 Error 的东西被归类到 Exception 中了。

Go 的问题主要是消极路径的代码在毫无收益的情况下污染了积极路径的代码，而且因为处理是完全手动的，所以很容易出现人为错误（忘了 if 忘了 return 什么的）。这个问题不要用可以加 linter 来辩解，语言本身设计缺陷需要加一堆其他东西就已经是个问题了，说 Go 做的好的，看看 Zig 和 Rust 这么做的吧。

你们使用 IDEA 而非诸如 Maven/Gradle 的构建系统吗，脱离 IDE 时怎么办啊

Go 的 comparable 其实是可做相等比较的意思…和比大小不沾边。

遇事不觉先打 explain

建议代码生成，Java 的 getter 有点过时了，考虑 Record 模式吧😋😁

我记得在这个软件的论坛上这个问题有讨论，作者自己实现了一个高效 regex

找到了之前买的佳宝的无花果
https://github.com/iseki0/blog/assets/13687964/dc3cf409-030f-4fad-9ab5-7dcd4d2c0561

@woshinide300yuan 仔细看了下，似乎市面上有好几种，包装都高度雷同，购买时需要仔细查看生产商

@luguhu @fzls 关键是都有臭味了啊😯第二次吃到这个味道的···

@NoOneNoBody 有没有推荐的质检机构，有时候还是比较闲的🥰

@fzls 他要是自建房，还在农村，只能自己搞土暖气了，不过一般都是火炕？

好了，大概可以拿营业执照去各大云平台什么的地方领一点企业福利？

volatile 所谓的可见性只是被用户总结出来的效果之一，显然不是说 volatile 只能保证这个。

@rockyliang Java 即使不使用 volatile ，使用 Lock 或者 synchronize 也会有一样的效果。
Java 对此的描述是 happens-before ，不是粗暴的 volatile 就可见别的不可见。

当然，解决这个问题的最佳方法是 ——写个存储过程