来源:知乎

Julia在高性能科学计算方面取代C/C++和Fortran是历史的必然,至于取代Python就不好说了。

这一点的原因主要在于科学计算的应用场景。

科学计算的应用场景

科学计算其实是很niche的一个领域,主要用户都是学术界或者工业界在一线搞研究的那些人,他们的共同需求就是需要从底层开始建构科学计算工具,而且没有现成的轮子。

有些人觉得拿py调调库,做一下data analysis就是科学计算了,那真的too young too simple。

Julia就是Fortran+MATLAB+Ipython的缝合怪,在做开发需要性能的时候可以写成Fortran,需要exploration来挖数据的时候用起来像是MATLAB或者Ipython,REPL各种交互。

Julia取代的其实是Fortran原本的科学计算生态位,这个生态位现在被python和MATLAB占了。但是这两种脚本语言说白了都是shell,只能调库,不能做原生开发(用纯py写个爬虫还可以,想用纯py模拟分子动力学就是在做梦),底层都是c/cpp。

如果有成熟的轮子的话当然py或者matlab用起来会简单很多。但是对于前沿科研中的新领域来说,根本就没有现成可用的成熟工具。如果想要快速开发一个性能可以并且用起来舒服的轮子的话,Julia绝对是最佳选择。这也是其设计之初的目标应用场景。

其实即对于做原生开发的人,他们的选择很有限,要不用cpp要不用fortran。但是这两个东西都不好用。

Fortran半只脚入土,虽然速度和性能依然一流,但是没有现代化的package management,没有现代语言的优秀特性和语法糖,甚至编译器都已经是历史古董了,盛产祖传代码,遗留屎山。

C/C++倒是能用,性能和功能都够,但问题在于过于底层,对于非CS专业的人来说上手难度极高,各种堆栈溢出,数组越界,数值爆炸就够非科班的老哥喝一壶。而且cpp本身是面向开发设计的,oop在科学计算领域远远没有fp用的舒服。更不说上千页的现代cpp规范,各种新特性的连学计算机的人都整不明白,精通C++不是笑话就是传说。

除非是大公司,否则你在科研院所或者大学实验室里面想找一两个能用cpp写东西的人那真是难如登天。用我老板的话说,他在能源部的国家实验室待了30多年,见过的能用cpp做高质量科学计算的人一个手就能数得出来。

Julia的生态位优势

Julia的生态位就是在这里,在很多专业领域,从业者写不来cpp又想需要底层开发搞新轮子,那必然直接Julia。性能到位,用起来简单舒服,哪怕写成全静态类型都比直接写fortran简单,更比cpp简单。

Julia的开发方面也做的很好,内置现代化的package management,虚拟环境,可以快速做prototype,非常舒服。

但是性能这个东西是相对的,看你的使用场景。这一点其实其他答主也说过了。Julia的动态特性是通过multiple dispatch实现的,函数的复用性其实是对不同参数类型做了不同的实现。不同实现中的参数是有固定类型的。如果你想的话,完全可以把Julia写成Fortran,所有函数给定静态类型,代码封装package,编译之后再用,性能完全不输cpp。但是Julia设计上有两种workflow,除了上面一种也支持REPL的交互式workflow。你也可以用完全interactive的工作模式,随便写跟python一样的dynamic函数,然后扔到REPL里做数据分析。

但是这一点上julia并不比python这种脚本语言更有优势,因为脚本语言用起来更简单而且py本身生态很成熟,其核心竞争力并不在这里。

但是从另一方面来说,这其实是Julia的另一个核心优点,因为很多搞科学计算的人既需要做底层开发,比如开发一种新的用于气候模拟的算法或者分子动力学模拟的算法,也需要搞数据分析,比如分析近年来天气数据或者量子化学实验数据。

在一个统一的生态系统里面,你可以避免使用两种不同的工具,你不需要在cpp和python之间来回切换,而只用Julia就可以了。对于没有历史包袱(比如花了10年精通cpp )的开发者,这可以大量节省开发者的时间,并且提高使用体验。

如果你在纯计算模拟,Julia依然可以实现一种新的混合式workflow,即先用高性能代码写库,本地环境做一下测试,测试完了直接扔进notebook整点随意的代码调库顺带配合画图脚本,跑出结果。

在Julia+Jupyter的完整生态系统下这是完全可行的。

这也是我目前在用的workflow,个人体验是真的smooth,另外,对于这帮每天用数学的人来说,Julia的很多的特性都很舒服。

内容中包含的图片若涉及版权问题,请及时与我们联系删除