从 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.

协程的切出点是可以确认的，所以考虑 data race 这类问题时会简单很多，协程的栈(当然我是指把闭包变量当做等价的栈)通常比线程小而且更加灵活

前几天刚收藏了下。这个重新编译的话需要梯子下载 chromium 的源码吗？

@kuanat 如果真的只在浏览器范围的话，但现在个人 PC 已经成 Electron 宇宙了，移动端也是各种浏览器套壳，如果浏览器开放 Raw socket 和文件系统权限，加上 ServiceWorker 后台运行。感觉现在的工具类应用相当数量都会被 Web 化。

作为特性，只和特定类型语言比没有意义。快速验证相关现在就是 python/js 这种脚本用的最多。

要说编译速度快，那脚本不是全秒了。
按照现在的发展情况看，我怀疑如果 TC39 不开摆，除了 C/C++和 Rust ，其他语言生态最终都会被绑定了浏览器的 JS/TS 占据。即使 JS 是一个槽点很多的语言。JS 的拖累还有 NPM 和 Node 的 Native 扩展。

实际浏览器技术放弃 native 插件并不只有 flash ，ppapi ，npapi ，NaCl 等技术标准都被浏览器放弃了，大概是跨平台和安全问题。且对浏览器来说维护一个这样的系统外，平台相关的扩展是一个很大的工作量。
而 Adobe ，我个人觉得，Flash 本身也是从 Macromedia 那里买来的，虽然也做了 AS3 ，但要完全迁移到现在的 HTML5 结构大抵也是要大规模重构的，对 Adobe 来说收益不能覆盖支出，没有动力做。

唯一的问题是，Adobe 一直不愿意开源 Flash Player 。如果开源搞不好会有更多人会去尝试做移植工作，说不定能把 flash 技术以另一种形式重现，也许是因为其中包含许可证问题吧。

@ccpp132 1 代就是 LibGDX ，一个 Java 平台上的游戏框架。2 代不清楚

塔防游戏还能有加联机功能的吗，什么模式的？

和版本管理机制关系不大。
这个主要还是 JS 这边的库生态的前向兼容做的太差了。
相比较，JS/Web 发展那么久也没把之前的设计失误的特性删掉，比如"==",自动创建 id 等。

只是改端口很容易被扫到的，要看密码爆破有没有日志记录，频率限制和 BAN IP 。web 看端口大概率还是没有 ssl 的，可能连个 wifi 都会被中间人一下，使用的服务出了漏洞被利用也是可能的

定义思考很困难。数学方面，现在其实是有机器证明的，还有证明逻辑严谨性的 LEAN4 。而且有些数学定理证明过程其实就是倾向于枚举的。总不能让 AI 学习去如何"注意到"。
不过做机器数学证明的性价比很低，大概也没多少资源愿意投入这个项目中。

C/C++的静态交叉编译，glibc 是个坑我得承认，感觉上 musl 静态编译的话应该还好吧？当然 C++动态库 ABI 那就是另一个天坑暂且不提了。