关于Moonbit-native方向的一点的畅想,望批评

首先叠甲,我支持现有 moonbit-native 存在的意义。
该话题只是讨论是关于 --target=X(native-lang) 的一些额外的畅想。
Moonbit的语言架构非常优秀,这是客观领先其它现代化语言的条件,并且它足够纯、也这正式因为这个基础,我才有这些畅想:

经历过 kotlin-native 的折磨,我和我的团队觉得,我们需要 --target=kotlin、–target=swift、-- target=ets 这样的编译器(甚至可以允许社区自己开发target插件),而不是像现有的 compose-multiplatform 一样,直接输出类似 --target=iosArm64 这样的平台二进制。

  1. 因为现在的Native-UI越来越多的使用声明式,就像 Compose、SwiftUI、ArkUI。而 Compose-Multiplatform、Flutter 本质上是面向一个画布在做多平台开发,在与 PlatformView 混合渲染时,需要解决大量的互操作性问题,并且无法规避性能妥协。
  2. 以 Flutter 为例,画布归根结底是画布,团队需要投入大量成本去模拟平台UI,这对于开发者来说也许是好事,但对于维护团队来说,可能也是一个问题。

如果我们真的有了 --target=X(native-lang) ,意味着moonbit能直接输出kotlin、swift、ets、dart,在ffi的加持下,意味着我可以通过ffi,来直接产出 jectpack-compose、swiftui、arkui、flutter 的代码,那我很乐意把我们的代码资产做迁移。因为这里好处是非常诱人的:

  1. 那么首先,生态问题就无需顾虑,就像当初kotlin寄生在java上一样,这种迁移是平滑的,收益是立竿见影的。
  2. 其次,是性能上也无需顾虑,像上文提到的GUI开发,跨平台的Native-GUI开放方案,需要维护团队自己去优化性能。而如果是直接变异成目标语言,至少原理上可比compose-multiplatform、flutter、arkui-x诱惑力大多了,吃的可都是官方平台的优化(特别是现在的ArkUI,不允许命令式的去做UI开发,社区里出现了各种奇葩方案,或者不得不考虑flutter这种画布方案,但这也就失去了ArkUI的优势)

不过,这里的存在的问题远比想象的复杂。比如每一种语言的多线程模型是不一样的,但我想,moonbit足够纯,也许也不是问题。
何况,这个方向就是要面对这些客观情况,至少我和我的团队是愿意去为这些收益去面对这些取舍的。

1 个赞

MoonBit 未来是否考虑,后期如果编译器完整开源了,让某一层 IR 相对稳定,允许社区开发 xxlang_of_moonbit, 类似于 Js_of_ocaml, Wasm_of_ocaml