纯函数式语言工程界都没怎么用，工程语言也就吸收点函数式语法糖，和正宗的函数式语言差远了，学生时代可以学，面向工作时代就没必要了。

JVM 上的其它语言（主动）学习的价值其实都不大，因为它们就是用来替代 Java 的，用的框架、编译结果都没啥区别。招 Java 写后端的公司也不可能让你进去写 Kotin （你跑路了怎么维护）。例外情况是，安卓开发需要学习 Kotin ，用 Spark 需要学习 Scala 。

写 Windows 桌面应用(electron,tauri,wails)可以用微软官方的 fluent ui：

https://github.com/microsoft/fluentui

1. strictNullChecks 肯定得开启吧，开启后 TS 就是 null safe 的语言了
2. 我是去年才学得 TS ，`declare`是不是属于被边缘化的语法，我在 handbook 中没学过，自己项目也从未使用
3. 类型允许 null 就应该增加检测 null 的代码，除非是逻辑需要，不应该用断言`!.`
4. 除开与外界的交互，项目中应该只使用 null 或者 undefined 一种来表示空(google style guide)

@CLMan 更正，“promise 不应该在 aysnc 函数里面使用”是错误的，应该是 async 函数不需要手动返回 promise 。

看了下 4 楼代码，确实学到了许多，特别是 promise 和 async 函数之间的关系。很多场合，async 函数还是没法替代 promise ，需要手撸 promise 。

@CLMan 看了下，4 楼的代码写的比我好。

promise 是 es6 加的底层 API ，async 是 es8 加的语法糖。

promise 不应该在 aysnc 函数里面使用，async 返回值会自动包装为 Promise 。

promise 的问题是不够直观，写起来心智负担较大，能用 async 和 await 就尽量别用 promise 。

```
function sleep(ms) {
return new Promise(resolve => setTimeout(resolve, ms));
}

async function waitUntilPresent(w, callback) {
while (w.main === undefined) {
console.log("sleep");
await sleep(100);
}
callback(w.main);
}

setTimeout(()=>{
window.main = "hello";
},1000);

await waitUntilPresent(window, main => {
console.log(main);
});
```

@boatrain1111 我作为一个过来者，认为他犯了初学者的毛病，指出来有什么问题？除此之外，我揣测了他什么？

个人是缺乏了解一些最佳实践，因此只能用最基本的功能。

1. 名校硕士校招
2. 大厂出身社招
3. 外包跳甲方，难而且收入不如 1,2

@CLMan 更正“不补充该领域的专业知识”，应该为“补充该领域的专业知识”
更正“看看其它语言是如何封装也是一个不错的思路”，应该为“了解其它语言是如何封装也很有帮助”

作为一个过来人，你犯了自学的通病：缺乏背景知识，然后钻牛角尖，后果是浪费大量时间成为了“计算机民科”。

一个学过数据结构与算法的人，除非他看了 PriorityQueue.toString()的文档说明，他根本不会调用`System.out.println(q1);`，因为在数据结构与算法里，堆实现的优先队列，其打印结果是未定义的。

很多喜欢吊"Java 源码袋子"的人也是这样，明明不懂，偏要分析来分析去搞得自己很懂的样子，就比如`java.util.concurrent`包，我敢说 99%的 Java 开发者都没看源码的必要。

正确的思路是跳出 Java 提供给你的封装，不补充该领域的专业知识，你这里就是“数据结构与算法”课程，再回头到具体的语言，看看其它语言是如何封装也是一个不错的思路。别一点领域知识都没有就去钻文档，钻源码，这样学习效率很低下，而且思维被 Java 的封装给局限了。

如果能预估最大容量，就是第 3 种写法。

go 的 slice 和 java 的 ArrayList 差不多，就是我们在数据结构与算法里面学到的基于数组实现的列表，基本的扩容策略是双倍扩容：每次 cap*2 ，摊还每次插入 O(1)。

所以第三种写法是在使用数组实现的列表时的常识，与具体语言无关。

按照编程的常识来：大多数语言都是放在文件的头部。

违背编程常识的 feature 发明，通常不是陷阱就是鸡肋，尽量避免使用。

年轻人别好高骛远，你把基础打好后面不是随便跳。

AI 加持的民科吗，话说骗子行业会不会因为 AI 得到进化。

@lhx888 粗略的看了一下，npm 注册表镜像的安全性是远远不如 debian 镜像仓库：

- npm 使用 `npm audit`进行包的签名检查，使用私钥签名，公钥检查，但似乎没使用证书体系（有待确认）
- npm 注册表允许私有签名（有待确认），但镜像默认不提供公钥，所以审查失败
- 执行`npm install`会触发`npm audit`，但是审查错误信息会被静默掉（只有在日志级别为 verbose 显示），不影响安装流程，直接执行`npm audit`会正常显示审查错误信息
- npmmirrors 官方推荐全局安装`cnpm`替代`npm`

所以前面一大堆回复都没人查官方文档吗，还是周末大佬不是加班就出去玩了，v2 的平均技术在我眼中断崖式下跌。。。

楼主考虑的是代理 /镜像导致的中间人攻击问题，npm 使用的是类似 debian 之类的软件包签名来解决的：

Signing and verifying published packages protects against an attacker controlling a registry mirror or proxy where they attempt to intercept and tamper with the package tarball content.

链接：
https://docs.npmjs.com/about-registry-signatures
https://docs.npmjs.com/verifying-registry-signatures

要了解实现细节，比如默认是否验证签名，验证签名失败会怎么样（会不会依然允许安装，会不会被用户忽视），是否存在例外情况等等，需要读 npm 的源码，反正是开源的。

@flyqie t/872745

@CLMan 这个才是官方说明： https://jakarta.ee/blogs/javax-jakartaee-namespace-ecosystem-progress/。