HarmonyOS 鸿蒙Next：仓颉对于鸿蒙真的是一个提升吗？
HarmonyOS 鸿蒙Next：仓颉对于鸿蒙真的是一个提升吗？
是的，性能有提升。但是一个重要的原则被打破了：单一职责原则。鸿蒙Next才发布，就已经存在2个主流的开发语言，让开发者的适配难度直线提升，这对未来的发展无疑是一个巨大的阻碍。
再说一个，ArkTS是方舟编译器对吧，编译器是自己的，那么对于ArkTS的魔改过程，是不是可以更大胆一点？语法是不是可以优化、增加，这并不影响对JS的兼容性啊。编译器都是自己的了，啥不能兼容？kotlin和java语法也不一样对吧，但是编译器层面都解决了，输出的都是class字节码。
不理解，不理解。在我看来，ArkTS就是一个临时的粗糙产品。
欢迎讨论勘误。
我支持你的看法，但是我更倾向喜欢仓颉。见识过C#、kotlin、swift的我，对于TS，无力吐槽，说的扎心一点，ArkTS连20年前的Java都不如，事实就是如此，ArkTS所谓的静态语言，当你认真去做了项目，你会怀疑你对静态语言的认知，并且TS对数据相关的处理，简直噩梦。
连扩展函数、扩展类都没有……来，咱不说swift、kotlin这些了，就连远古OC、C++都支持扩展函数、扩展类啊。
在没有准备好的情况下，仓促推出ArkTS真的是对的选择么？仓颉才是赶上了21世纪10年代的现代化高级语言，和kotlin、swift一个梯队的。由此可以遇见，仓颉才是鸿蒙未来的路，不论是性能、还是高级语言的开发优雅性，魔改的ArkTS远不如，别信官方说的那一套：“两个都可以，仓颉做高性能应用的”。作为老码农（深度使用过GO、JAVA、swift、C#\C++）的心里话，语言本身就是工具，是和计算机对话的一种过程而已，对于开发者来说，只需要更好用的语言。同一个平台两个语言，我肯定选择最现代化的对吧。
现在的问题很尴尬，花费了大力气开发的ArkTS应用要维护吧，但是仓颉才是鸿蒙的菜啊，项目肯定要转仓颉对吧。但是你再看看仓颉和ArkTS的互调用是多么的操蛋，但是这我能理解，这种问题原因，仓颉和ArkTS本身就不是一个体系的。你说java、kotlin，都是可以跑在JVM上的。OC、swift都是LLVM底层。三方库管你什么语言写的，都能用，对吧。起码做到了平滑迁移、完全互兼容。
在鸿蒙还是Dev版本的时候，推出ArkTS是真的动过脑子么？系统还没release，就已经有两种体系的语言了。Android、iOS发布那么多年，也才替换语言，而且同时做到了平滑。
复杂性的提升，不是这么简单朴素的。事物的发展往往出乎意料。只要2个事物可以交织，就一定会交织。我们假设，你主要使用ArkTS，依赖的SDK可能使用仓颉。反之也可能成立，这时就由不得你自己了。
