初试 Julia 语言

上一篇博文中推荐了 Python 的 JIT 编译器 numba，这两天又用空余的时间尝试了一下最近的一个新兴语言 Julia。Julia 的目标设定得很高，未来是要成为一个速度上接近甚至超过 Fortran/C 这样的传统语言的通用编程语言。然而就我这两天很初步的尝试结果看来，它也许有这个能力，但至少目前，对工程计算的人来说，还没有达到 production-ready 的程度。（当然，这只是基于我个人的编程经验和需求的结论，很可能不适用于其他人。而且Julia本身是一门相对年轻的语言，很值得持续关注。）

之所以这样说，有三个方面的理由：

1. 作为一个动态语言，它的 JIT 编译器（在很多情况下）还没有智能到，让我可以同时享受动态语言的便利和它的速度优势。例如最近我在试用 Julia 时最先尝试的就是把原来用 Numba 写的函数重写一遍，然而发现结果非常不好。Julia 版本的函数执行速度相当于纯 Python 的速度，与 Numba 版本相差三个数量级，占用的内存也异常地大。后来发现，最主要的原因是三层嵌套循环中，循环长度我按 Python 的习惯定义为变量，而在 Julia 中不变的全局量最好声明为常量。仅仅这个修改，让速度提升了两个数量级，但还不及 numba 的速度。进一步的测试还可以通过一些细小的地方来进一步提升速度，如这篇文章做的那样，最终高度优化之后速度也许可以达到接近 Fortran。但是，如果要这样做，为什么不干脆用 Fortran 呢？相比之下，numba 的可用性就要高太多了。不过毕竟它现在的稳定版本还是0.3.10，还需要再给它一点时间发展成熟。

2. 作为一个新兴、小众的语言，相关的工具链还太弱了。没有合格的 IDE，Juno 在我看来现在连半成品都还算不上。包管理似乎是用的 Git，有时会出一些奇怪的问题，这时候用 Pkg 倒还不如手动去管理。调试程序也比较痛苦，一方面是很多错误信息跟没给差不多，像我这种不熟悉的人基本只能用 print 一半一半地查，另一方面是相关的调试工具也还不够好用。

3. 文档、相关信息还太少。已经有不少人开始使用 Julia，但网上公开的信息中，官方的文档还比较简陋，其他用户贴出的博客也很少。这导致在遇到问题的时候，很难快速地难过 Google 直接得到问题的答案，而往往需要在社区中等待圈内人士的解答。

另外一个对 Julia 印象不太好的是，官网给出的 benchmark 没有多少参考价值，至少其结果中 Python 和 Matlab 都很有问题，多半是单纯地逐行翻译出来的程序。这就跟我把 numba 的程序直接翻译成 Julia，然后得出结论它很慢一样，是不公平的比较。

不管怎么样，Julia 目前看来还是值得持续关注的，但是目前，我还不会考虑把它作为主要的计算语言。