首先叠甲，我支持现有 moonbit-native 存在的意义。
该话题只是讨论是关于 --target=X(native-lang) 的一些额外的畅想。
Moonbit的语言架构非常优秀，这是客观领先其它现代化语言的条件，并且它足够纯、也这正式因为这个基础，我才有这些畅想：
经历过 kotlin-native 的折磨，我和我的团队觉得，我们需要 --target=kotlin、–target=swift、-- target=ets 这样的编译器（甚至可以允许社区自己开发target插件），而不是像现有的 compose-multiplatform 一样，直接输出类似 --target=iosArm64 这样的平台二进制。
- 因为现在的Native-UI越来越多的使用声明式，就像 Compose、SwiftUI、ArkUI。而 Compose-Multiplatform、Flutter 本质上是面向一个画布在做多平台开发，在与 PlatformView 混合渲染时，需要解决大量的互操作性问题，并且无法规避性能妥协。
- 以 Flutter 为例，画布归根结底是画布，团队需要投入大量成本去模拟平台UI，这对于开发者来说也许是好事，但对于维护团队来说，可能也是一个问题。
如果我们真的有了 --target=X(native-lang) ，意味着moonbit能直接输出kotlin、swift、ets、dart，在ffi的加持下，意味着我可以通过ffi，来直接产出 jectpack-compose、swiftui、arkui、flutter 的代码，那我很乐意把我们的代码资产做迁移。因为这里好处是非常诱人的：
- 那么首先，生态问题就无需顾虑，就像当初kotlin寄生在java上一样，这种迁移是平滑的，收益是立竿见影的。
- 其次，是性能上也无需顾虑，像上文提到的GUI开发，跨平台的Native-GUI开放方案，需要维护团队自己去优化性能。而如果是直接变异成目标语言，至少原理上可比compose-multiplatform、flutter、arkui-x诱惑力大多了，吃的可都是官方平台的优化（特别是现在的ArkUI，不允许命令式的去做UI开发，社区里出现了各种奇葩方案，或者不得不考虑flutter这种画布方案，但这也就失去了ArkUI的优势）
不过，这里的存在的问题远比想象的复杂。比如每一种语言的多线程模型是不一样的，但我想，moonbit足够纯，也许也不是问题。
何况，这个方向就是要面对这些客观情况，至少我和我的团队是愿意去为这些收益去面对这些取舍的。