C: it is mostly alright, especially since C99 with VLA and complex numbers. Yet the aliasing rules are a bit annoying, and multi-dimensional arrays, while possible, do not really feel natural.
C++: an unholy clusterfuck... I almost ended crazy trying to use it properly. With extreme discipline maybe you can get to do some work with it. But not me.
Octave: very beautiful language with a natural, concise notation for math. Excellent out-of-the-box support for sparse matrices. Shame that loops are so slow; needs a serious effort on a JIT.
lua: my favorite general-purpose language. The luajit interpreter may be one of the fastest and easiest alternatives to Fortran. I wrote a matrix product using an explicit triple loop, and it multiplied huge matrices just slightly slower than an optimized blas. Extremely impressive! I'm very sad that the project is sort of "abandoned".
python+numpy: My least favorite, but the one that I use the most... what can I say: this is a general-purpose language where you can sort of do math in it. But it is not a language tailored for math. The base language has natively strings and dictionaries (for which I have no use) but it doesn't have native multidimensional arrays of floats. I do not understand why the numeric computing community is shifting so much to python, it makes no sense in my eyes. Also, loops are insultingly slow.
Julia: may be the best of the bunch, but launching the interpreter is excruciatingly slow, and it does not suit my usage. In the time that julia uses to compile a three-line program to plot "sin(x)", you can run one hundred times the Fortran compiler on the equivalent program (or simply call gnuplot). All in all, it keeps pretty much the promise of "matlab with fast loops", which is just what I need. But I feel that it's still a bit far from being there.
Yes, I tried it upon its release and, while much faster, the startup time is still dramatically sub-par, especially when loading packages. This means that when I call Julia scripts from makefiles, etc., a considerable amount of running time is spent in re-compiling over and over the same packages. I agree that my usage pattern is not at all representative, but still it seems that Julia is not a good "unix citizen", since it tries to force you to do everything inside its own REPL, instead of the native one. This is indeed my main point of friction with Julia. If it started instantaneously it would be essentially perfect. This is not a matter of dividing the startup time by 2, but at least by 200.