The biggest Julia cheerleaders gave up years ago. That doesn't mean the language is dead but it's not a great sign for a niche lang

Julia is by far my favorite language; I used it all throughout grad school for my research. The problem is that it doesn't have enough of a network effect in industry. I've begrudgingly switched to Python for my day-to-day work.

Actually, what is the current status of Julia? Can anyone in the know share a bit on the perspectives as they stand?

They're in the run-up to their first stable release at the moment (I think they're aiming for August, but could be wrong about that). I can't speak for popularity, but development is certainly going strong.

The biggest Julia cheerleaders are using Julia.

uf, I’m a working mathematician and just reading julia’s documentarion makes me dizzy... I do not think it fits this use case.

This might be a better intro http://ucidatascienceinitiative.github.io/IntroToJulia

Sure, thanks. I am always put off Julia because of the documentation.

That's ironic because I find Julia's documentation to be the second most clear documentation I've seen (after elixir). Notation wise, Julia is the most comfortably close to mathematics (APL is closer, but it's a write only language). I'm not a working mathematician, though i did graduate with a rather theory based math degree.

The documentation is fine but IMO written more for developers. We do need more mathematical-based introductions which introduce the right packages for working mathematicians. I am a working mathematician myself and find Julia to be the perfect language for it because its abstraction is on actions instead of on data representations which fits things like functional analysis extremely well.

Things that are OO based like C++ and Python are pretty bad at representing math because they put forward an idea of the actual representation (the object) as what matters, instead of the actions it performs (the function overloads). This may be good for some disciplines, but in a mathematical algorithm I really don't care what kind of matrix you gave me for `A`, I just want you to do the efficient `Ax=b` solve and have the action of the solver choose the appropriate method to abstract away the data. In Python you'd have to tell it to use the SciPy banded matrix solver, in Julia your generic ODE solver will automatically use the banded matrix solver when it's a banded matrix. This then allows for a composibility where the user overloads the primitive operations on their type, and your generic algorithm works on any data representation. This matches the workflow of math where an algorithm is proven on L2 functions, not on functions represented with column-wise indexing and ...

I've written a custom GF256 data type and used Julia's builtin matrix solves (note: required monkey patching in Julia <~ 0.6 because there were one and zero literals in the builtin solver) to do Reed Solomon erasure coding... It's glorious.