Julia? Look, I enjoy playing with Julia, but have you actually used it? Because most of the people I meet who turn up their nose at Python and say nice things about Julia haven't ever used Julia. It's got great potential but has some major gaps and warts, and is just plain dog shit slow for certain things compared to SciPy, which, you may not be aware, is basically C and Fortran code wrapped in Python API.

> is just plain dog shit slow for certain things compared to SciPy

Do you have real examples here or is this just FUD? SciPy is not known for using absolute state of the art algorithms or perfectly optimized implementations. It can be pretty easy to improve on the naively implemented or legacy pieces of SciPy, e.g. http://tullo.ch/articles/python-vs-julia/

I do follow Julia development and I am aware that it isn't quite there, but at least their community does embrace JIT compilation, not like Python that PyPy is just yet another project, ignored by the reference implementation.

> SciPy, which, you may not be aware, is basically C and Fortran code wrapped in Python API.

Which for me personally means, that I would rather C and Fortran directly or better yet, a C++, .NET or Java binding to them.

> Which for me personally means, that I would rather C and Fortran directly or better yet, a C++, .NET or Java binding to them.

Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages.

Scala, Clojure, F# also allow it, with the added benefit of industrial strength JIT/AOT compilers.

Except without the great Python ecosystem and without great projects like Numpy/Scipy

Numpy/Scipy are only relevant to a minor set of computer users, and even then, there are alternatives like LANPACK and BLAS.

Also Java and .NET ecosystems are just a little bigger than Python.

> there are alternatives like LANPACK and BLAS.

LANPACK + BLAS = scipy

> Numpy/Scipy are only relevant to a minor set of computer users..

> ... Java and .NET ...

Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages.

> LANPACK + BLAS = scipy

Thanks, I already knew that.

> Being able to describe things with a syntax that looks almost like pseudocode and runs highly-optimized C/Fortran code to do heavy lifting has huge, huge advantages.

Hence we are back at Scala, Clojure, F#, enjoying the respective AOT/JIT native code compilers, and integrating with that highly-optimized C/Fortran code.

I use Scala and Clojure. I like F#. Have you ever worked at an actual business that needs to hire developers that know these languages WELL? I can tell you that the significant added cost can't be justified by the not-very-big benefits compared to just using Scipy.

> Scala, Clojure, F#

Functional languages. The "year of Linux on the desktop" of programming languages. Also none of those look like pseudocode (Scala does if you ignore bits and squint).

The amount of job postings say otherwise.

No they don't. On stack overflow jobs F# has 14 posts, closure 28 and Scala ~100. Python has 400+.

Other sites have similar totals. But they are filtering for London/UK/Europe, so that might be a bias.

This made be wary of Julia: http://danluu.com/julialang/

Julia's nice, but it's playing catch up to R & Python. Name any statistical algorithm, and R probably has it. Name any scientific field, and there's probably a Python library for it.

Some people are very productive in Django and Rails (and the like), in non-performant languages. Many sites never grow to the size where running on the JVM (or AOT-compiled Go) would save you money from fewer servers vs. more coder-hours.