cool!

@CC11001100 这种常用的功能，以前没泛型搞着别扭没人搞，有泛型了常用的工具函数基本都有泛型实现了

这种基础功能没必要单独搞个库吧 https://github.com/samber/lo/blob/master/condition.go

匿名模式、访客或者新建一个帐号

第三次法国

org-roam

协程本质上可以看作可挂起恢复的用户态轻量级线程，可以在没有多线程的环境下模拟并发，也可以在多线程环境下替代系统线程降低切换消耗，支持更多并发。

只不过现在大多数语境下，协程的挂起和恢复条件通常就是 I/O 操作，异步 I/O 操作正好和协程的挂起恢复匹配，所以协程和异步 I/O 也经常一起讲。

而 goroutine 、yield 、Promise 和 Future 都是协程的实现，只不过实现方式不一样。goroutine 是 stackful 实现，其他是 stackless 的。

我 IDE 、Emacs 和 Vim 都用：
- IDE 省心，功能全，在特定语言特定项目这个维度，用 IDE 心智负担会低很多，毕竟别人是靠这个赚钱的，喜欢 Emacs/Vim ，搞个 Keymap 也大差不差
- Emacs 现在我主要就用 Org Mode 和 Magit ，然后还有其他一些临时编辑、文件管理啥的，整体是脱离项目这个单位，面向全局。IDE 打开一个项目还是会占用一定的资源，启动也慢，这时 Emacs 就很舒服
- Vim 就只在终端用了，比如 cd 到某个目录后想简单编辑下某个文件、服务器上需要编辑配置等。所以我需要 Vim 的配置足够小，启动速度足够快。

对于编辑器来说，配置越重，功能越强大，启动也越慢，这个时候和 IDE 比资源占用上也没多少优势了，还不一定有 IDE 好用。

在我看来 Emacs/Vim 的优势首先在设计哲学上，然后才是扩展性。

Emacs 自底向上的设计，所有的功能都可以绑定在一个 key sequence 上，不同的 mode 可以有自己很独特的设计，org mode 在 emacs 中就能自成体系，其他的编辑器中的移植很多时候还是差强人意。

而 Vim 的 Modal Edit 是比 Vim 本身适用范围更广的东西，也许你没用 Vim ，但很多时候也会间接用到 Vim 的部分快捷键或者 Modal Edit 。

而独特的设计意味着就算能在其他编辑器 /IDE 中复刻一部分功能，但也还是没有在原生环境中舒服，这时，在 Emacs/Vim 能满足需求的情况下，我会更愿意用 Emacs 和 Vim 。

而 IDE 就很直接，简单，大而全，扩展性受限，但大部分功能都有了，用就完事。

短期不用想

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

在我看来 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 的优势在于简单，新人几天就可以上手，同时先天异步，打包出来的容器镜像小，启动速度快，天然适配云生态。