pursuer

@Seanfuck service worker 不能跨域

从 LLVM 出现之后，大部分语言中间语言都用 LLVM IR 了，先编译成另一个语言再编译要解析代码两次浪费时间，以前还没有 LLVM ，没有标准的中间表示所以会选 C/C++，这样支持的平台比较多。

最重要的是生态，造轮子大部分都是浪费时间，综合来看现在是 JS/TS(前端 Web 生态唯一选择，强大的动态和调试能力) 和 C++(Linux 和 Windows 等平台的 API 原生支持以及跨平台库支持(libuv))，然后 Android 上需要补充一个 Java ，基本只做 binding 。

本来想看看 Zig 来代替 C++的，毕竟 c++不用协程，写异步以及内存管理真的很麻烦。但转念一想用的不多还是算了

@w568w
c++生态还不错，但包管理就不行，当然这也没办法，毕竟要面对的相当广泛的平台。要是以后 WASM 成为 C++的"JVM"说不定能有新突破？
另外 C 互交互里 ABI 不兼容是个巨大的坑，所以我现在跨语言交互尽可能优选 RPC 了

@RedNax 走 wasm 是会有序列化性能损耗的。而且 wasm 生态还有个 assemblyscrip 更是和 TS 十分接近的写法，移植不是更容易？话说回来这些写惯 TS 的这些开发者能忍得了 Go 的拉胯的类型系统和类型推断能力也是神人了。

把 typescript 里的 sync 调用改成 async 的 issue( https://github.com/microsoft/TypeScript/issues/1857) 挂着没改，整了个 Go 的，给我气笑了。真要把这个作为 TS 后继版本，那些使用了 typescript 的 API/transformer 的 JS/TS 代码怎么办。我需要性能的时候我直接 transpile 忽略类型检查不就行了，真的是没活可以咬打火机。

之前写过一个 WebAssembly 的 JIT 编译运行时
https://github.com/partic2/pwart
但是有点懒得继续跟进新特性了，后面接着加复杂度那我不如拿 TCC 来改个 C 的运行时，可能还简单一点。

21 ，有一些 PDA 设备版本比较早。有的机顶盒设备甚至 4.4 的都有。。对我来说 21 最大问题是 libuv 需要 24 ，所以我 patch 了一个支持到 21 的版本。其他的直接 webview 糊，webview 如果用 X5 的话，能到 Chromium89 ，基本够用，不知道 geckoview 能到哪个版本。反正不管哪个 SDK 版本都觉得原生 API 既碎片化而且太难用了，不怎么想在上面写复杂逻辑。

c/c++的 ABI 和版本问题一直存在，所以微软搞了 COM 。同时依赖不同版本对于很多语言/平台都是比较麻烦的问题，只能指望开发人员做好兼容处理。

“拓展一下，如果我要写一个 C++程序也用到这个 otherlib 库，但同时又有一个依赖需要高版本 libcrypto.so ，那我是不是就没办法编译了？”
静态链接并做符号隔离(RTLD_LOCAL)可能可以解决，但如果可能，我觉得还是做成 RPC 的调用方式会简单一点。

关于 CLS ，之前我做过一个尝试 https://github.com/partic2/protask

如果是通过 babel 或者 typescript 将 await 降级为生成器的话是可以实现一部分，但原生 Promise 会有影响。原生 await 则完全不行，相关讨论在这里
https://v2ex.com/t/1081474#reply29
我没看过 zone.js 的实现不确定是否有类似的地方。

随后我把上面的 protask 库改回了生成器的模式。但通过代码编译自动添加 await hook 还是可以实现类似 CLS 效果的。并且不会影响原生创建的 Promise.