@Wxh16144 @UnluckyNinja 再补一个. 在*历史*commit 的 diff 界面(不是跟 head 执行 diff), vscode 没法跳转到函数定义(这个函数可能不在当前代码库里头), idea 就没这个问题

@UnluckyNinja 这个 diff 是跟 head 的 diff 还是非 head 的 commit ? 前者的话 rust 也能显示 structName 后者的 rust 不行

@Wxh16144 随手找的一个例子.
这个 vscode 的 git diff
https://imgur.com/vmLjcmq

这是 idea 的 git diff
https://imgur.com/a/BTVAAs1

@kk2syc 那你这咋进行加减乘除的计算呢 ?

@yh7gdiaYW 所以才需要重构

同意 @NessajCN 的观点. OP 估计是个初学者, 别整那么多花里胡哨的, 先装上最新的 golang 就行, gvm 就算了吧, 估计也用不到多个 golang 版本

`is_can_submit` 这个命名方式好奇怪啊

@powersee @sagaxu 跟 go 的相比, 还是有些差距, golang 的 example 能在线运行 (点开 example 有个 run 按钮), 能集成到 CI 里头 https://go.dev/blog/examples

@aababc golang 的官方文档感觉比 java 好多了, 起码有例子. Java 文档全是字, 有的时候写的真是又臭又长

https://pkg.go.dev/sync#WaitGroup
https://pkg.go.dev/sync#Once
https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#interrupt--
https://pkg.go.dev/container/ring#Ring.Do
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/BlockingQueue.html

对比下两者 regexp 的文档
https://docs.oracle.com/javase/8/docs/api/java/util/regex/Matcher.html#replaceAll-java.lang.String-
https://pkg.go.dev/regexp#Regexp.ReplaceAll

@lvlongxiang199 主要介绍了 modern cpp (cpp11+

有编程经验的话, 可以看 a tour of cpp 及 cs106L

为啥不自己构造数据试下呢

shopify 也用单体. 贵司的业务比 shopify 更复杂 ? 为啥他们的单体没崩 ?
https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity
https://shopify.engineering/shopify-monolith

这里说的 IDE 应该是 jetbrain 他们家的. 之前搞 presto 的时候, 在 Linux 下方便些, 就在 hyperv vm 里头起了 https://hub.docker.com/r/kasmweb/desktop 通过 webUI 来使用 Linux 里的 IDE

建议还是把这类话题的给挪到 每个月都会出现的那种主题: https://www.v2ex.com/go/monthly

隔一段时间就会提出这些问题, 我都怀疑这是不是为了故意给自己制造热度
https://v2ex.com/t/1089194
https://www.v2ex.com/t/1023860
https://v2ex.com/t/1078535
https://www.v2ex.com/t/1049518

我更偏爱 if err != nil, 控制流看着更清晰些. java 里的 `Integer.parseInt` 如果失败, 就直接抛异常. go 里的对应方法, 返回 (int, error), 能提醒调用者处理异常(给个默认值, 或者向上抛). 但没搞出类似 rust 的 `?` 的语法糖来避免 if err != nil 满天飞这点没得洗

感觉说 java 啰嗦大多是因为, 业务逻辑一行都没写, 先定义一堆 interface (哪怕只有一个 class 实现), 在定义一堆 setter, getter, toString, eqTo (有了 Immutables 能好很多)

我还是比较反感 orm, 稍微复杂点的 sql 用 orm 实现就费劲, 而且生成的 sql 不可控, 没法做些优化. 以及 n+1 之类的问题 https://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/

多提一句, 感觉 golang 不适合做 web, 更适合搞重网络 IO 的应用

@seedhk 可行. 但 ck 没有 join reorder, 写 join sql 的时候得是大表在左, 小表在右, 否则性能比较差. Doris 优化器做的还可以, 也可以考虑 Doris

复杂查询估计是 AP 类型的, 建议上 clickhouse/Doris

救急的话, 与其上 redis 不如考虑拆分实例, 核心服务读/写单独的实例, 通过 DTS 把数据同步到复杂 sql 读的实例, 这样开发的工作量小些