能否从技术层面客观，不带有情绪输出的评价鸿蒙HarmonyOS NEXT？
别的不说，我只说代码。具体来说，我只说一说鸿蒙系统的应用开发语言ArkTS语言。
因为是门外汉，先上官网介绍：初识ArkTS语言 | 华为开发者联盟 (huawei.com)
你只用看一下官网这里面的一些截图的示例代码即可，比如：
然后，作为对比，我们可以看一看与ArkTS同源的另外一门语言AssambleScript：介绍 | AssemblyScript 中文网 (nodejs.cn)
因为是门外汉，所以也是看一下网页链接里的截图示例代码即可，比如：
export function fib(n: i32): i32 {
var a = 0, b = 1
if (n > 0) {
while (--n) {
let t = a + b
a = b
b = t
}
return b
}
return a
}
这俩语言的语法都是C系的，极为相近。然后这两个语言的关系是这样的：JavaScript（JS）作为弱类型语言，其静态类型的超集是TypeScript（TS）语言。然后ArkTS是TS的改进优化，AssemblyScript（AS）则是TS的子集。
AS的演进方向是较为彻底的提升性能（因此其不兼容JS的绝大部分库），而ArkTS的演进方向则是在保证兼容JS生态的情况下尽可能提升性能（当然出于性能考虑，ArkTS对JS库的兼容做了约束）。
从代码介绍上看，我猜ArkTS走了一套和安卓很相近的路子（当然这和AS即WASM技术路线也很相近），只不过安卓用的是Java虚拟机，而鸿蒙用的是JavaScript生态的JIT(甚至AOT)解释器/虚拟机/编译器。
这样的话就说的通了，因为技术上确实是可以落地（有AS语言的范式可以参考，也有JS语系的解释器V8引擎可以参考），当然从具体落地来看，仍然相当考验技术实力。
之所以一上来要提AS语言，因为AS的这套模式我认为和ArkTS很相近。AS编译为.wasm文件，这是个字节码而非机器码文件，然后通过V8引擎将.wasm字节码在用户本地端编译为机器码，从而实现接近原生的性能。当然V8对.wasm的处理仍然是JIT解释，而非AOT编译，一个很重要的原因是V8对代码的优化/去优化考虑。
而鸿蒙这里，因为ArkTS是在TS强类型+静态类型的基础上改进的，所以它具备和AS类似的实现方式的可能。当然考虑到ArkTS要兼容JS生态，所以我猜ArkTS可能的实现方式有3种：
- ArkTS项目代码 => JS字节码 => JIT运行时（即V8引擎，性能等同于JS。这个应该已经废弃了，我只在古早的B站视频里看到有人披露）
- ArkTS项目代码 => 方舟字节码（类似.wasm的思路，二进制字节码文件） => JIT机器码（类似.wasm的思路，能用上ArkTS静态类型的能力，性能会比JS-V8强，宣传是“接近原生性能”)
- ArkTS项目代码 => 方舟字节码 => AOT机器码（安装App时执行AOT编译，则性能即为原生性能）
从我个人看B站分析视频的情况来看，之前最早是走的第1种实现。目前从官方手册来看，很可能走的第2种实现，其实性能不差了。当然我们期待能早日走到第3种实现。
为什么我会这么推测呢？主要可以看这页：ArkTS高性能编程实践-学习ArkTS语言-基础入门 - 华为HarmonyOS开发者 (huawei.com)
这个页面里说到的性能优化建议和V8引擎的优化建议的思路非常像！然后从Array<number>建议改为Int8Array等描述来看，其实就是在向AS看齐的。