Try to do machine learning in Julia; it is difficult. If I want to say fit a gradient boosted tree or SVM its not support in Julia, whilst appears in Python/R libraries. Also, with Spark being more and more popular in the data science landscape, the lack of Julia bindings is also a no for the data scientists I work with (Spark has Python/R bindings).
You will have to reach a little deeper for machine learning methods not supported by Julia. XGBoost has a Julia interface and you can google Julia SVM for myriad of alternatives. Packages like Mocha and MXNet are a few deep learning alternatives. PyCall is also an easy solution for interfacing with Python for things such as pyspark. It also has some of the most convenient to use parallel / distributed computing tools for numerical computing.
Point being that even if Julia is not there to replace Python, there is still a strong case for using it as a way to augment Python workflow.
If Julia just want to replace Python as the glue interface, it seems to have no chance winning...What it can do, as a glue layer, that Python cannot do?
It's much easier and lower-overhead to call into C, Fortran, and soon even C++, from Julia than it is from Python. If there's a library in Python but not yet in Julia, it's really easy to call into Python from Julia.
What you can do in Julia that you can't do in Python is write high-performance library code in the high level language. If you need to write custom code that isn't just using stock numpy or scipy algorithms right out of the box, and needs to use custom data structures and user-defined types, Julia is a fantastic choice. You can try with Cython or Numba or PyPy, but you're either working with a limited subset of the language, or forgoing compatibility with most of the libraries that people use Python for.
Julia feels like writing Python but does not allow some of the semantically impossible-to-optimize behaviors that you can find in Python, and has a type system that you can use to your advantage in designing optimized data structures for the problem at hand.
As to my own experience dealing with data, the degree of freedom, as basically a programmer, is small. Specifically, I have to think and bear tools in my mind from the start. Which might not be ideal, but cant avoid anyway.
It's not meant to compete with Python as a glue language. The point is that you can start using Julia right now and be productive by calling other languages' libraries to fill in the holes.
Well, what do you work on? Julia isn't for everyone.
I use it because it has quite good numerical primitives, and I can quickly make a slow, Python-like first pass at an algorithm, then profile and get C-like performance in the bottlenecks with minimal effort. And if I need a particular library, I can call Python's. Also: macros and multiple dispatch make a big expressiveness difference for my type of work.
Lifetime values, customer segmentation, lead scoring, customer life cycles, customer attrition and also quite a bit of reporting. Some text analysis. I use R because it offers superb speed of development, extensive documentation, commercial support and many partner opportunities with the likes of Oracle, Microsoft, Alteryx, Tableau, Tibco and pretty much every analytics vendor. In my experience, R's slowness has been greatly exaggerated.
Yeah, I would use Python for this kind of task, too. Vectorized operations are fast enough in a lot of cases, and the library advantage is important. At this point in time, Julia is a great C/Fortran replacement, but for Python/R/Matlab, it's a trade-off.
The core language is general purpose, and IMO really good for high-performance work, but the community is focused on numerical code, so there aren't a lot of libraries for non-numerical/scientific/financial work at this point in time.
That report is over a year old, which for a 4 year old language is a very long time. The top comment in [1] is from a week ago and highlights why it is now mostly invalid.
