Julia语言的优越性体现在哪里？有潜力取代C、C++等吗？

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的很多的特性都很舒服。