@weiwenhao #33 大语言模型已经在力大飞砖了，编程语言生态还在分裂。我觉得一门编程语言生态非常重要。很多人说编程语言只是工具，但是我真不想用不同的工具造相同/相似的轮子了。

我很好奇被 Go 语法简单的吸引的用户，其他语言的高级特性不用也没什么影响。而 Go 这样衍生语言很多什么 go+,walang 还有这个 nature ，最终也是将其他特性丰富的语言的碎片组合，除了使生态分裂，感觉也没什么好处。

现在大模型靠算力力大砖飞，让我觉得现在才出现的新语言前景更微妙了。

我今天碰到了，开 Persistent Log 好像好了，但不知道是不是只是碰巧好了

@alect 不卡和底层漏洞没什么关系，是那些卡的 APP 塞了太多垃圾代码了，当然也有一些踩坑的经验。

@Radeon ESM 不能满足我的需要，我的目标是前后端使用同一套模块加载机制且足够灵活(比如支持通过 indexeddb 加载模块,在加载前预编译代码等)，所以 ESM 的灵活性对我来说是不够的，而且 service worker 内不支持 dynamic import ，所以才做了 pxseed ，AMD 只需要 require,define,requirejs 3 个变量也还好

怕污染可以 rollup 打包 AMD ，虽然我觉得污染影响不大？
顺便打广告，一个利用 AMD 实现前后端共用代码的框架 地址 https://github.com/partic2/pxseed-CorePackages

txiki.js 应该可以更小一点，我也想在 txiki.js 上实现 node 兼容的，但不太顺利，网上找到的 polyfill 大部分都是针对浏览器环境，对 node 服务器侧的支持很弱

C++的话 Boost 算是一个比较完整的解决方案？
不过我没搞过

现在前端都直接发布 es module 了吗？感觉 es module 还是灵活性比较差

@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 既碎片化而且太难用了，不怎么想在上面写复杂逻辑。