Reason, ClojureScript, AssemblyScript 你更看好哪门语言的未来？

我能说我都不看好么？

【注意：所谓看不看好未来，主要是指我对语言未来的流行度和发展趋势的估计，并不代表我对一个语言的喜好。比如说我不看好ruby的未来，但是我挺喜欢ruby的。】

先说ClojureScript。三者中我最不看好的就是它。我每次碰到题叶都会劝他弃了ClojureScript的坑……

在我看来，ClojureScript有几个很要命的问题。

第一，它是一个动态语言。如果我们要在原本js的领域替换语言或者进行多语言编程，当然希望找一个能弥补js弱点或者跟js能形成互补关系的语言。按照这个标准，我们一般首先考虑的是静态语言。而ClojureScript显然不在其列。比较来说，Clojure之于Java倒是一个选择（如果你想选一个动态语言来配合的话，但别忘了Groovy）。

第二，Lisp流派和JS（以及其他主流工业语言）差得太远，原本的编程方式和经验很难快速平移到新语言，基本上就是从头学起。

第三，Lisp社区本身是比较分裂的。Clojure虽然号称是现代Lisp，但也未必受其他Lisp方言社区的待见。比较刻薄的说法是，Clojure好的地方都是从Lisp那里来的，不好的地方都是Clojure自己发明的……

以上三点决定了ClojureScript很难走出小众，几乎不会有大厂投资，这反过来会影响语言的推广（有好爹非常重要！）和在工具链上的投入（最终一个语言好不好用很大一块是工具链决定的）。我个人印象，ClojureScript的使用者主要是Clojure社区的存量用户，像题叶这样从JS转ClojureScript的应该是凤毛麟角。

然后说Reason。你对比ClojureScript，就会发现Reason的优势。

第一，Reason是静态语言。（顺便说明一下，Reason是ML一系的，并不是Lisp方言。）

第二，相比较Lisp的『古怪语法』（其实是没有语法，直接手写AST），ML一系看上去更像正常的编程语言，尤其是有F#和OCaml两个大哥撑腰。Reason本身其实可视作语法JS化的OCaml方言，别管其他，至少在吸引JS程序员上是很有诚意的。

第三，Reason有大厂光环（Facebook），Reason有牛逼工具链（继承OCaml工具链）。其中重要一点是张宏波的BuckleScript编译器，完美体现了OCaml+Facebook这对好爹妈的优势（张宏波出自OCaml核心团队，Facebook给捐助让他可以没有负担的做开源）。

但是呢，即使Reason的前景比ClojureScript要强多了，我也不是很看好Reason。主要原因如下：

Reason其实不是一门独立语言，只是把OCaml的语法改了一下而已。这或许降低了前端入门OCaml的门槛，但是也只是降低了一点点而已，你稍微深入一点就发现还是要学OCaml才行啊，比如OCaml的标准库。表面的语法相似也可能反而带来一些障碍，比如你最终要明白Reason里的 [a, b, c] 并不对应JS里的数组，而是链表（ [a, [b, [c]]] ）。

另外，这个语法改造其实也比较主观，未必见得所有JS程序员就领情，比如OCaml是基本不写分号的，但Reason却改成了必须写分号，对于使用前置分号风格的JS程序员反而是个倒退。再如match改成switch但是并不用case关键字而是改成了竖线，也显得有点半吊子。

Reason的主要好处里，静态类型、牛逼工具链其实也都是TypeScript的强项，最重要的差异化卖点其实是在FP上。但是React社区以外，是不是有那么多FP粉？Reason是否能真的吸引到很多JS工程师转投？这一点是存疑的。另一方面，即使Reason吸引了不少React社区的人从JS转投Reason，但也很可能他们深入之后直接写OCaml而不是Reason了……所以Reason更像是一个从JS到OCaml的诱导性语言，其存在的理由本身反过来也是限制了其发展上限。

最后是AssemblyScript。它和前两者是完全不同的，它的编译目标是WASM而不是JS。所以它延续WebAssembly的特点，和JS并不是取代关系而是互补关系。它的竞争对手根本不是ClojureScript和Reason，也不是TypeScript等，而是可以编译到WASM的其他语言，如C、C++、Rust等。AssemblyScript比它们的优势是语法贴近JS（其实是TS），语义贴近WASM底层和JS（标准库照抄JS）。

那么我为什么也不看好AssemblyScript呢？以下原因：

WebAssembly很大一块use cases是移植现有的C/C++库到web platform，在这点上当然就选C/C++了，没有AssemblyScript（或者Rust等语言）啥事情。

如果是基于C/C++第三方库开发应用，道理上我们是在写胶水代码，那么WASM要跟其他可以编译到WASM的语言竞争，同时也跟JS本身竞争。在语言的熟悉度和工具链的成熟度上，AssemblyScript显然对任何一方都没有优势。特别的，AssemblyScript相比成熟语言目前有很多特性是不足的，因为它贴近WASM底层语义，所以要等待WebAssembly本身的相关规范定案。

此外AssemblyScript是有自己runtime，用GC的，而不像C/C++/Rust那样。这导致那些需要排除GC的cases恐怕不能选择AssemblyScript，另一方面对于可以容忍GC的cases，则其他所有带GC runtime并支持编译到wasm的语言（如Go、Kotlin等）也同样成了竞争对手。

唯一AssemblyScript可能占据优势的场景是，JS/TS程序员因为某些目的（比如为了性能）需要从头写一个相对简单的WASM模块（目前不能太复杂的原因是语言特性还不够，最好也不能用很多GC），那么贴近JS/TS的AssemblyScript比其他语言有优势。但这种场景到底占比有多大呢？我很怀疑。JS/TS程序员固然可以较容易地使用AssemblyScript尝鲜WASM，但从工程角度看，无论公司还是个人，可能并不能得到足够支持继续投资于AssemblyScript的收益。所以从基本盘来说，反而是比ClojureScript和Reason更不确定的。

好了，最后总结一下。这三个语言都是广义Web/JS平台下的语言，其未来取决于其是否能吸引足够的Web/JS程序员。所以虽然三个语言我都不是那么看好，不过具体来说，还是可以区分的：

一、我对ClojureScript是看衰。ClojureScript很难吸引Web/JS程序员，其主要来源是JVM平台上的Clojure用户，但Clojure语言本身在JVM平台上也受到Scala、Groovy、Kotlin等语言的压制，未来不容乐观，长期来看，估计只能靠老祖宗『lisp』的招牌苟延残喘。

二、我对Reason的看法是会继续发展，但上限比较低。Reason的主要用户来源应该是React社区中追求更好的FP（对JS不满意）编程体验的用户，但是一方面React自身改得越FP（比如React Hooks）Reason的吸引力反而越低，未来JS加入的一些FP新特性（比如pipeline operator、const value等）也会降低Reason的吸引力。进入Reason的用户也可能并不会一直停留在Reason而是以其为跳板渐渐直接转向OCaml甚至F#（如果F#能出现媲美BuckleScript的JS编译器）。

三、我对AssemblyScript的看法是它可能是这三个语言里潜力最大的，但是基本盘不明，不确定因素比较多。比如WebAssembly本身的发展势头，其他竞争语言对WASM的支持等。最关键的是，AssemblyScript自身的工具链能否快速和持续发展，而这很可能取决于AssemblyScript能否傍上好爹，以获得持续支持——而这一点是最难确定的。目前AssemblyScript的核心开发者只有两人，虽然社区支持势头似乎不错，但是开源项目能否持续很多时候是看运气（这都是命）的。

以上。