Far from 90% of code written in the numerical world is Fortran/C. And even the code that end up being written in Fortran almost always starts its life in something like MATLAB or Python. Only after all the kinks have been worked out and all the bottle necks identified might some of the code be ported to Fortran or C. And even in those cases it often only makes sense to rewrite the most critical 10%-20% of the code.
In addition, all of these higher level languages popular in science seem to have pretty good support for calling existing C/Fortran libs when necessary. Julia is no exception, which makes it possible to take advantage of all the work that's been done developing optimized numerical codes.
That said, I would like to see something more automatic. In my limited experience, Julia's ccall works as advertised, but f2py in Python is much simpler to use.
it's trivial to call c from julia. the first project i used it on, the julia wrapper around cairo (the svg library) didn't support something i wanted. just reading the library code i figured out how to extend the wrapper in about half an hour. it was three lines of julia code. i was very surprised / impressed.
I think it's meant to compete with the likes of MATLAB, Python/Scipy and R which are probably the most used languages in scientific research.
As it stands now most prototyping is done in one of those high level languages and only if you really need the speedup do you port it to C/C++. Julia wants to be a high level dynamic language where you get the speedup for free.
I think the idea is that you can move the threshold on when to implement in Fortran/C(++) since you only have a '1x-5x slowdown' for most common application compare to the 20x-5000x slowdown with R/Python/Matlab/..
