会的不难，难的不会

我觉得 java 业内最宝贵的财富之一就是这么多年积累下来的这些方案和方法。

飞书

会不会是 java 没识别到分配的 cpu 数，线程池按照虚拟机总 cpu 数创建了，导致线程太多？

99.0.4844.51 复现

Java 运行在虚拟机上，框架利用 JVM 的特性可以将很多的编码成本抽象出来，一个注解就能让你省去很多开发成本。同时支持泛型，语言本身的表达能力也会强很多。

Golang 虽然有 runtime ，但是运行时能够做的操作很有限，性能也差，泛型还要 2 月 1.18 才有，框架能做的事就很有限了。代码复用要么写多份，要么 interface{} 满天飞，要么代码生成。比如 GORM 一堆反射 + interface{} 带来的类型信息丢失就很烦。现在有了 GORM GEN 会好一些，但还是靠的代码生成。

Golang 的优势在于简单，新人几天就可以上手，同时先天异步，打包出来的容器镜像小，启动速度快，天然适配云生态。

@ungrown 猝不及防

Powershell 背靠 .NET 大树，与其说是 Shell ，不如说是 DotNetScript

我们之前有类似的情况，拆分了微服务，然后又比较懒，直接在 rpc 服务上定义了前端需要的接口，通过网关做了协议转换。

后来是有一个聚合 http 服务来单独提供前端需要的接口。

cli + magit ，gui 主要在解决冲突的时候用

太强了

git cli + magit + idea reslove merge conflict

忘记是什么地方看到的了，linus 做出来 git 的时候好像就只有 cat-file 、update-index 、write-tree 这些基础命令，但是这些命令直接拿来用太难了，就又有人在这些命令的基础上包了一层 add 、status 这些命令。

也许别人那会想的也就是能用就行，哪想到现在使用会这么广泛

力哦

https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md

```
This is the design for adding generic programming using type parameters to the Go language. This design has been proposed and accepted as a future language change. We currently expect that this change will be available in the Go 1.18 release in early 2022.
```

要素过多 hhh

开发分支 rebase，合并 master fast forward merge

对于编辑器我的定位就是轻量级开发工具，项目开发商业化产品的 IDE 还是比自己配置一个出来靠谱的。

会