fortran语言和python语言_对于科学计算，大家对新出来语言Julia怎么看，相比C、Python和Fortran有什么优势发展？...

三更：

先抛事实(经与支持julia的 @陈宁聪 同学确认)：julia的抽象类型的容器是被做了派发(aka “模板偏特化”)以非组合类型的方式实现的

这个派发(相比于非派发的值语义组合类型)是性能不佳且没有对这种不佳性能warning的

设计上，julia接近于java的堆分配类型(即使是标量)，没有栈分配类型，实现上的优化特化(或者说派发，割裂，etc)另讲

REPL很不错，是julia一大比cpp强的卖点

再说个人看法：julia对内置常用数据结构都要搞派发，听闻此事的我只能送大家一张表情包：

std::vector //不会有人不知道这啥意思吧，不会吧不会吧？julia的堆分配、以REPL为卖点等等，说明julia的重心仍然在小项目的开发便捷而不是大项目上。猜猜看这些特征更像C++还是Python？

julia完全不是社区宣称“可以挑战重写blas”的水平

它只是一个对HPC表现更和善的scala，比Fortran高很多，比Python快很多，而实用价值欠缺，最深层次的力量又远远比不上C++

C++最深层次的力量也不是谁都需要的

原答：

语法简单、高性能、表达能力强，三者最多只能同时拥有两者。julia宣称三者兼具，其实是用大量宏实现的(表面上的)语法简单。宏这种东西能对ast做任意修改，本质上已经是元编程的范畴了，当注解可以任意解释你写的代码的时候，本质上你写的不同段落都在跟不同的解释器打交道，你很难说这其中有什么语核不变性，也很难说「各有各的简单」可以是这「一个」语言的优势。

要高性能和表达力，用C++

要语法简单和高性能，用numba

要语法简单和表达力，用Python

julia表面上可以写出很抽象的代码，可以一套泛型输入输出，像Python一样优雅自然。然后呢？如果不通读核心开发者的代码，何以知道类型注解如何改善性能？更进一步，连续数组下标访问的时候，不通读代码，何以知道@inbounds？

julia必须直面两个问题：全部强类型情况下，为什么不使用C++？(嫌C++不safe的话我们也有rust)

jit部分的优化技巧大量来自纯理论解释和实测数据/经验，而这两部分是相当割裂的，即使julia宣称是一个「面向jit的语言」，也没有一个trivial的profile思路来指导人「面向jit优化」。普通开发者无从得知jit过程中获得和未获得哪些优化，完全是一个黑箱。

时至今日，工业界普遍在往静态类型语言上转向以提高代码的健壮性和进一步优化的可能性，而julia给出的ast宏和「无类型注解时当做泛型」无疑是强大的「元动态性」。这种动态性提高资深用户的生产力的同时，也在提高开发成本、交流成本和测试成本。它或许是一个很酷的语言，但想要真正获得完善的工具链以支撑不同需求、不同层次上的开发规范、性能分析、代码审计，离不开一个强大的社区的支持。

而科学计算社区，呵呵。

更新：关于 @陈宁聪 所说的julia泛型与cpp模板的等价性：所以对于每一个不同的类型T都会产生不同的编译代码。Julia的JIT技术和Rust/Clang的LLVM编译器实现没有实质上的区别，只不过Julia把编译推到了运行时(而且还有GC的问题)，这和做科学计算的人的工作流程是有关的，在REPL中一个一个代码块的边执行代码边做实验，而不是先把代码全部写好再编译执行，所以不可能一次性获得所有的信息。基于C++的REPL也必须带着所有的模板运行时编译(见ClangJIT，和Julia一个原理)。

我不知道

template

T f(std::array a){

return T{};

}

怎么一一等价的翻译出julia？

至于按照这个逻辑，人们同样也无法理解如何在基于LLVM的Rust和基于Clang的C++中优化，我已经指出了Julia的JIT和这两个没本质区别(有GC除外)，当然我知道C++有专门的工具可以查看生成的代码中到底哪些优化有哪些没有(这倒是Julia比较欠缺的)，但你要说大多数普通开发者会用我是不信的。再说了，那种“一个trivial的profile思路”在任何地方都根本就不存在，loop会不会unroll，constant有没有传播，函数会不会inline，可不可以开fastmath这种东西从来就不直观，更何况还和指令架构有关(应该这么说，要靠经验摸索。。。)，编译器优化本来就是很古怪的东西，Julia论坛上找出LLVM优化的Bug又不是一次两次了。

对没错我说的就是专门工具，一个会用cpp、会专门去学julia的HPC开发者，大概率是会用专门工具的。至于“普通的HPC开发者”是否等于“普通开发者”，可以理解为我手滑。

py和cpp都有更好的profiler和debugger，新特性迭代速度不输julia，同时又有各行各业共通的强大社区更好的覆盖暗坑、bug，提供更多更系统化的workaround，在工程意义上会比挨个摸索和不断承受未知的API break更接近于我所谓的「trivial」。与此同时julia只解决了一些科学计算的痒点而不是痛点，还为此冒出来了一些奇奇怪怪的新痒点，结合后发制于人，会形成生态小->发展速度慢->生态赶不上的闭环，所以除了吸引特定需求的少数计算组，我不认为它会是下一代科学计算基础语言，不认为有革掉Cpp/Py命的实力。

二更：

陈同学比我更清楚julia的细节，包括细节缺陷，比如：倒是被推断为Union的概率更大，也会伤害性能。例如一个x先是整数，然后又是浮点数。这个时候会被推断Union{Float,Int}，后面这个情况反倒是比较麻烦的。

julia基本类型里的Any属于黑洞类型，一旦半路出来Any，后面就直接AnyScript(于是对于“类型级数”式Union，也是类似的道理)。必须要时刻有意识@code_typed才能防范这种问题，而没有健壮的IDE自动提示，没有lint和ci，jit的时候连个warning都不给，这种对性能干扰极大的存在竟然是完全隐式的，竟然是被容器支持的，这就非常不trivial。

陈同学也提到了一些julia独有的优势比如REPL，我的意见是见仁见智，这东西对于小项目来说很常见，但很多小项目不需要高性能；对于大项目来说，类型推导不要有Any和奇葩的Array布局这么天马行空的东西要更重要些。唯独确实有个领域经常是小项目+高性能，那就是造轮子的时候。这或许可以解释为什么julia的轮子那么前卫和开发那么活跃。

虽然开发活跃≠沉淀稳定，所以大项目我个人还是首选cpp就是了