@lesismal 你说的没错，进程间通信机制这样的东西就是大厦的基础，是砖头，但是编程时如果每次自己去搬这一个个砖头这既不符合 DRY 的原则也不够“少”。async await 算是结构化并发的一种落地形式。
你不能说封装的程度高就一定是不好的，软件工程是权衡和妥协，君不见 Go 相比 C 不是也隐藏了许多细节吗，每个函数开头插入栈空间检查未必是个多么高效的选择，当年也有人因为用了“高级语言”就被喷浪费了机器性能。
systemd 出现之前，如今一个 .service 文件搞定的事情要一位 bash 熟练工写上成吨的 .sh 还不一定好好解决问题。看上去 shell 里的每一个命令都好简单啊，但是组合起来的结果你能说这是“简洁”的吗。当然这个我不多说，我相信每一个工程师都很清楚。

此外 Java 的轻量级线程和 Go 的 goroutine 差不多一回事，当然 syscall 该卡还是卡，go 也是在 IO 等等地方特殊处理掉的，这个不是应用程序自己做点什么就能解决的。（其它关于 Java 的内容我就不评论了，这个看场合见仁见智

@lesismal 事实上如果 Java 在绿色线程出现之后不能及时安排好结构化并发，我敢说 unhandled exception 可以被静默忽略的特性一定会成为灾难。

@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 只能保证这个。