短期不用想

在另一个脚本语言的某个脚本中见过这种写法，挺巧妙的

在我看来 Java 中的 DI 是转移复杂度的一种方式，将 Bean 的装配转移到框架完成，开发者只需要标记需要什么 Bean 就行了。

Java 纯 OOP 的设计会导致项目中存在大量的类和接口，同时会创建出大量的 Bean ，手动装配这些 Bean 是一件很费事的事情，因此使用 DI 是很有效的转移复杂度，减负增效的方式。

而 Golang 虽然支持一定的 OOP 特性，但中小型项目中类似 Java 中需要装配大量 Bean 的场景并不是很多，引入基于代码生成或反射的 DI 框架会反而会带来额外的成本，增加复杂度。

Golang 本身是一个「简陋」的语言，硬是往 Java 的模式上靠往往会带来额外的复杂度。

会的不难，难的不会

我觉得 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.
```