理论上来说，操作系统和编程语言应该是解耦的，比如说你用C++可以在Windows上开发，也可以在Linux上开发，Java也是一样。

但过渡到移动手机操作系统时代以后，OS和编程语言的耦合度突然变得非常紧密了。比如说，我们可以看到安卓的成功，有一大半是因为选择了Java作为主要的开发语言，迅速拉拢了大票的开发者；而苹果也是下了非常大的力气在推广Swift，让这门语言与iOS强捆绑。

背后的原因，可能包括多方面，但我想，移动OS在开发便捷性的高要求以及生态的诉求方面，很多都落实到了开发语言上，也就逐渐形成了编程语言也是OS的一部分，这种局面。

这个问题同样提给了鸿蒙，与鸿蒙配套的开发语言是什么？

我们先来看目前的，官方的答案，主要有如下几点：

1、鸿蒙开发支持JS，Java和C++三种语言，开发者可以选择自己擅长的。

2、三种语言可以混合使用，在混合使用的时候，建议用JS做界面开发，用Java做业务逻辑，在性能要求严苛的情况下，用C++开发。方舟编译器在后续会实现三种语言的混合编译，同一套运行时支持。

3、鸿蒙将来会推出新的语言，这种语言会跟Type Script比较类似，但会针对鸿蒙的应用场景进行优化。

这个官方的答案，不能说不完整，不周到，可以这样说，这是一个基本不会错的答案。

但在我看来，这不是一个精彩的答案，因为我觉得这里面有几个问题无法回避：

1、并没有给开发者一个明确的倾向，开发者看了这个答案以后，其实并不太清楚自己该如何准备/改造自己的技能栈。当一个开发者或者团队，决策采用某一平台的时候，他们一定会把自身的能力和目标平台进行一个对比，看自己能力是否匹配，需要进行哪方面的不足，而面对官方的答案，开发者的感觉是好像是啥也不学都行，也好象是自己好多都不懂，用来测量的尺子本身就不严格。

2、一定程度上加重了设备开发者的负担，让我们假设一个较小的硬件产品开发团队，他现在要做一个跟手机配套的应用，这个团队可能只有一个软件工程师，他以前可能只会嵌入式C，现在又要学习JS在IoT设备上做界面，又要学习用Js和Java在手机上写程序，而且由于IoT设备的FA/AA与手机上的FA/AA要通盘考虑，无法简单去外包，这么一坨，可能就需要这一个工程师扛下，这个压力有点大。

3、并没有很好地体现鸿蒙的三大技术特点：分布式、易开发、可裁剪。我认为鸿蒙的编程语言，至少要把这些技术特点，映射到语言上。比如说分布式，那是否可以参考类似区块链智能合约的Solidity等面向分布式应用的语言特性？可裁剪的特点是否可以通过类似编程单元的抽象来得到很好的体现？易开发就更不用说了，如何有效缩减代码量，如何有效处理不同设备的界面描述？hml其实是很好的一个尝试，但在手机鸿蒙上有抛弃了这个东西，转而继承安卓的界面处理方式。

这几大问题都是事关重大的问题，对鸿蒙的推广影响非常大。

这里我也想花一点时间谈谈我对各个候选语言的一些看法：

JS：优势是学习成本低，发展势头猛；缺点是性能有天花板，不擅长处理数据，语法也比较随意。

Java：优势是目前受众最广的语言，而且已经在安卓取得成功；缺点在于本身并不擅长做界面，虚拟机，JNI也一直被诟病，同时可能存在致命的法律风险。

新语言（可能叫仓颉Char）：优势是可以重新设计，取长补短，同时有利于建立独立的生态；劣势在于需要付出很大的精力去推广，发展成熟也需要一定的时间，与鸿蒙的节奏未必对得上。

综上所述，希望鸿蒙的技术团队，能够花足够的时间，对开发者的实用场景进行非常深入的调研，对技术实现进行更前瞻性的探讨，做出果决而清晰的决策，能够拿出一个经得起考验的技术发展路线，让所有的鸿蒙开发者都受益。