是我接触的太少了
我平时是用GR的backend做图，不过速度还是一般，数据一大就不行。 Gadfly的色彩渲染比较好看，不过慢到吓人。DataFrame的速度和pandas差不多，不过比r的data.table慢几倍以上。JLD的读取速度非常慢，比R的data.table读csv还要慢十倍以上。
我个人认为Julia需要在data science方面提高很多，毕竟data science的用户远远多于做numerical computing的。不过说实话我还是更愿意看到Julia像Matlab一样专注于提高性能，花里胡哨的东西少搞。
首先要分清楚MATLAB是一个商业软件，其实作为商业软件不太容易像Python这些开源的通用语言有一个比较广的社区（当然MATLAB可以很容易地制定目标用户的计划）。而作为开源的通用语言，很难说指导这个社区做什么，对于Julia本身开发者来说他们只能不断地提供更好的编译器和语法支持。至于用来干嘛真的就是各显神通了。
HDF5作为二进制文件应该不会比CSV慢啊？你可以新开一个帖子看一下你的benchmark么？然后也可以试试JLD2.jl
JLD格式不是用来读CSV的哈，如果要读CSV就用专门的CSV包
然后这个十倍以上我觉得很有可能你把编译时间也算进去了，如果只读一次的话，因为现在的JIT不会先解释执行所以第一次运行一定会进行JIT的trace。测试性能用 BenchmarkTools.jl 才比较公平。
使用方法很简单
@benchmark xxx
绘图本身大部分的场景其实不需要JIT（因为可能也就画一次），我觉得这个将来这个包发展优化好以后就能解决这个问题（也就是静态编译Julia的代码）其实这个包起初也是有人觉得绘图程序太慢做的，不过还是不完善。
现在Julia对于只需要运行一次就能完成任务的场景不是很合适，因为这些场景很有可能压根不需要JIT。这个就需要等编译器底层进行一定的修改了，但是并不是不能做的。
我试过把csv的数据用r的data.table::fread读和在Julia里面转成JLD在读，100万行15列左右的data frame在Julia里面读起来非常慢。我一般直接用@time算时间，貌似不包括compilation时间吧。而且读取数据一般都是一次性的，这样的话compilatiion时间也要考虑。
如果用@time是算上了编译时间。如果只是比较速度就不公平。
但是实际上确实对于这种一次性的任务会更慢，只能等待类似于V8的技术用在Julia上面了（如果依然要保持动态性）。不过我不认为这个在技术上未来实现不了，只是不知道要到什么时候了…
如果写好的代码需要部署，可以用AOT编译器把这个overhead编译掉。
如果你用@benchmark 应该可以获得更准确的时间（因为会运行很多次）。
我觉得Fortran本身发展不慢，但是相关的库却好像没怎么发展了。如其他人也提到的那样，Fortran加入的新特性也越来越多。但是，有多少人去用这些特性就是另一回事了。比如我在一个Fortran群Fcode里面请教过大家Coarray的问题，居然没有几个人听说过，更不用说帮忙解答了。
Fortran的用户群体都是和我们一样搞科学计算的，可能多数人没有计算机基础知识，不懂程序编译过程，不使用版本控制，不懂性能优化，甚至都不会调试。我认识的人里面写了一两年Fortran还没用过Module、allocated array的多的是。这也怪不了他们，他们只用把程序跑出来能出论文就行了。开发Fortran的这些包总得有人来做啊，但是谁愿意做呢？水平低的或者有别的活的人不会去做，水平高的人写的东西可能也没人用。
现在有Julia这样的东西在，完全可以试试的。Julia的一些包有时可以达到和Fortran相关包相当的速度，比如DifferentialEquations。此外，Fortran也不总是很快，如果不仔细挑选编译器和函数库，可能计算也快不了。比如gfortran就比ifort慢很多。另一方面，Julia才1.0，在此之前还没有多少统一的标准，所以包的开发也很难一直跟上，编译器的优化也远远不够，这个都是可以期待的。
同意。Fortran的这些库好多都是77风格的，新一点的95用的人还可以，2003以及以后用的人不多。Fortran学起来很容易，原生的向量数组用起来很舒服。据我所知九十年代在美国的金融领域还有一些人使用Fortran, Kenneth French也是用Fortran. 不过现在已经没人用了，美国几个大的金融数据提供商都不再提供Fortran借口了。现在使用Fortran的应该主要在academia, 或者搞HPC的同学。
stackoverflow里面Fortran高手很多，貌似年龄都偏大。
语言的性能主要在算法和对硬件性能的利用率，Fortran这两点都不占优势。我个人觉得Julia还是有一个非常promising的前景的，希望能够在国内积累一些玩家。
我对Julia在国内的adoption的担忧主要在三点。第一，大学老师用的都很少，学生做科研也没有动力学。第二，公司用的更少，不利于就业。第三，网络环境太差（下载慢学习材料少），盗版太容易找到（好多人情愿使用盗版windows也不用linux, 盗版matlab用的人很多）。
1 个赞
个人感觉，Julia的流行是早晚的事情。由于他底层对python、fortran、c、c++的支持，以包的形式扩展进来，可以有效的利用这四种语言提供的库。
以我个人为例，数据常规处理和一些统计计算以及画图，python的效果，而且有着很多的机器学习算法可以直接调用。而一些图形上的几何算法，则可以调用c/c++库，速度不比直接用c/c++慢，更何况可以直接出图。
另外，最重要的，我是做最优化算法的，一些最优化工具Ampl都是收费的，一些算法求解器在其它语言上提供的接口并不是特别友好，而julia居然有针对这些求解器的包可以做统一的模型描述，这让我还是非常惊讶的。
无论是自由的语法表达还是便捷的部署，以及虽然年轻但是很好用的IDE，外加能够包罗万象的包管理，这些都是它能够快速发展的基础。
先不要着急诟病它的缺点以及不是特别靠谱的生产环境，毕竟，它才刚刚1.0
2 个赞
如何定义一门成功的语言是个问题，好多domain specific language非常成功，但是用户不多。如果说语言的成功和用户数量挂钩的话，从历史看来，设计上占优势的语言不一定会成功。我从Julia 0.4 开始用，非常同意你提到的这些优点。However, these merits do not necessarily translate to ultimate success. 请看这个：
https://www.jwz.org/doc/worse-is-better.html
不过，我对Julia的未来还是很乐观的。
我觉得需要有killer application才能流行起来。但是Julia实际上目前的用户数量已经足够支撑它不死掉了。（according to Quora）
所以我们是可以放心用，不用担心以后死掉。至于流行不流行就随缘吧。
别被大公司用才是成功的这句话洗脑了就行…
代码执行上的效率还是很难达到的，目前Julia的BLAS库还是调的Fortran代码，虽然现在社区里也有人正在研究用纯Julia实现BLAS，但感觉一时半会还是赶不上Fortran优化多年的成熟库，对这块感兴趣可以关注一下官方slack的#linear-algebra频道。 如果考虑开发效率，Julia有着显著的优势，在实际开发中，对于效率要求很高的部分，可以用Fortran实现，然后从Julia调Fortran。由于Julia调Fortran的FFI非常简洁，所以这里产生的two language problem不是那么的明显。
优化了的BLAS不是Fortran写的。优化BLAS用的是C和汇编（真正的计算部分）写的。Level 3 BLAS的结构是这样的。
http://apfel.mathematik.uni-ulm.de/~lehn/sghpc/gemm/page02/index.html
Julia要写BLAS的话，可以用纯Julia写packing的部分，然后复制粘贴优化的汇编到 Base.llvmcall 调用汇编作为microkernel。
前面提到的纯Julia BLAS是指这个：GitHub - JuliaBLAS/jBLAS.jl: Julia BLAS library.
只知道Base.llvmcall是用来调用LLVM IR的，如何用它调汇编呢？具体有例子么？
可以这样用汇编
julia> function foo(a, b)
Base.llvmcall("""
%X = call i32 asm "leal (\$1,\$1,4), \$0", "=r,r,r"(i32 %0, i32 %1)
ret i32 %X""",
Cint, Tuple{Cint,Cint}, a, b)
end
foo (generic function with 2 methods)
julia> foo(Cint(1), Cint(2))
5
2 个赞
DifferentialEquations 其实比Fortran快的 
。