目前来说wasm的使用很少, 而且仅仅作为javascript的补充. 长期来说moonbit会一直以wasm作为输出格式吗? 就目前业界情况来说, 参考rescript以javascript为输出不是更加通用, 或者说容易推广吗?
如果moonbit是作为通用语言, 也许可以参考kotlin, 通过不同的编译选项可以生成不同的输出格式. kotlin目前支持jvm, js和wasm等多种输出格式. 很有一统全栈的野心.
2 个赞
长期来说moonbit会一直以wasm作为输出格式吗? 就目前业界情况来说, 参考rescript以javascript为输出不是更加通用, 或者说容易推广吗?
长期来说我们会支持多后端的。
作为一门新的语言，我们需要解决一些用户的确实痛点，考虑到wasm生态上我们相当于填补了一些空白，容易吸引到一些刚需用户。Moonbit完成了从0到1的积累以后，自然会考虑其他平台的，技术上都不难，主要是还要培育不同平台的生态，需要更多的资源，一开始先聚焦一些。
6 个赞
冒昧问下, 为什么不直接使用rescript来生成wasm, 而选择发明一门新的语言呢?
编译到 js 的目前已经有很多成熟 (流行) 的语言了, 但能编译到 wasm 并且好用的, 目前貌似只有 rust. 但 rust 使用难度是比较大的. 能编译成 wasm 目前是月兔独有的优势.
相比 rescript, 窝更喜欢月兔的语法. 可能因为窝喜欢 rust 吧.
1 个赞
wasm 的运行时可以做的很轻量, 最轻量的方式可能是把编译器分离出去 (比如 wasmer). 就是先在一个地方把 wasm 二进制编译成 native 的二进制代码, 比如装到一个 .so 文件里, 然后另一个地方需要运行的时候, 直接从 .so 文件加载代码 (内存映射) 即可开始运行. 在运行的地方可以不需要编译器.
运行 js 基本上是需要 JIT 的, 所以应该是需要随时使用编译器的.
高性能的 js 虚拟机 (比如 v8) 其是是挺重量级的, v8 完整的源代码占用几十 GB 的硬盘空间, 编译一次 v8 需要 2 个多小时, 编译后的 v8 大小 100 多 MB.
wasm 运行时可以在更多的地方运行, 就是多种操作系统, CPU, 及其组合.
除了 x86, 比如 arm, 甚至 RISC-V, 目前看来 wasm 运行时的支持比 js 虚拟机要好.
还有一些硬件资源很少的设备, 比如 OpenWrt 路由器, 128MB flash 已经算大容量了, 在这种设备上塞一个 js 虚拟机很难.
3 个赞
moonbit语法也有让人不舒服的地方, 比如函数定义居然还区分顶层和局部
wasm不只是javascript的补充，其特性很适合做进程内隔离的serverless，性能优化起来比javascript简单很多
2 个赞
主要是Wasm虚拟指令集,像IIVM IR一样, 以后可以方便转义和桥接.
当然,其实作者可以自己设计一套全新的指令集,
主要是看意愿衔接什么生态, 自建生态还是别人的生态.
我倒是认为应该着眼于未来, 为国产处理器和平台设计, 比如龙芯与摩尔线程这些.
==========**********************==============
我认为国人确实应该自己设计一套指令集, 目前大家做的都是用西方人的指令集 JVM V8 LLVMIR … 哪样不是呢, 甚至龙芯都是用西方人的指令集, 就是不知道摩尔线程的GPU是否开发了自己的指令集.
我想说这样是不行的, 永远无法发展出自己的独立体系来.
设计指令系统又不难,为啥就是不愿建自己的自建平台呢,我们又不缺人手.
其实是可以的
但是得衡量下收益投入比，不能为了创新而创新
1 个赞