Wow, that is a great way to grow up. I would have liked mathematics dinner conversations growing up.
I think what holds Julia back in that space is not its undisputed technical superiority but it (not yet) being as friendly to such users as, say matlab. I would be surprised if much matlab code my superstar colleague runs is longer than 100 lines or takes more than 10 seconds to run. And he dictates what an entire large team codes very complex things in.
He in particular has been a stubborn Fortran77 programmer since ever, but the younger best programmers he has worked with are mostly modern-Fortran programmers. Then many less coding-oriented people use Matlab, as far as I know, but there has been an important shift towards Julia recently.
I am one of those who love coding as a scientist. Binary distribution is not necessary most of the time. And Julia boost my productivity at least 10x if not 100x as compared to C/C++. I have a little experience with Matlab. However, I think it is too rigid and fragile. I hate the way it manages functions etc. I also coding Python for several years. I found Julia is a prefect one to replace it in my work due to heavy PDE stuffs.
While I completely understand where this sense comes from, I think it’s a bit unfair to compare given the existing size and inertia of those other languages.
In my experience, having taught beginners in both python and julia and to a lesser degree R, that none of these languages is easier than the other. They all of pain points, and they all have conveniences. Actually, I find Julia much easier to teach, since I have to do way less “just ignore the why here…”, but if I’m being honest, students struggle in similar ways.
In truth, python, Julia, and R are good enough for almost all users, and the reality is that most scientists are too busy with non-coding stuff that they are not going to take the time to rigorously evaluate what is “best”, and will just do what the people around them do. And this is fine.
I do think threads like this are valuable as long as they stay respectful (which this one has), but the truth is, must of these points are known, and are either not directly solvable (we can’t magic a giant ecosystem into existence) or are being actively worked on and making strides (reducing TTFX) or have potential solutions/hacks, but aren’t high the highest priority (static binaries).
There are plenty of us that find Julia extremely productive. Some folks are making libraries that are better than any existing in any other language (eg the whole DiffEq ecosystem). As more scientists focus on Julia, or make things that are indispensable, or train their trainees in julia, more users will come.
In my field (biology) perl was completely dominant for a long time. There were arguments about python when it came on the scene that it would never rival perl, but we can see how that turned out (there are still bioinformaticians, most in their 60s, that still argue for perl, but their influence is waning).
Time will tell if Julia comes to displace other languages, or remains a small niche, or goes a different way. For now, use Julia if you like it, contribute if you can, and always feel welcome to share your thoughts or ask questions 
Yes. Fully agree.
Researchers with no interest in computers find it too complicated compared to R and Python.
When people talk about a “programming language” they usually conflate (fair enough, though) a lot of aspects into one (language semantics, runtime, tooling, ecosystem, package management…).
There’s a lot to be said about the overall pros/cons of all of these for languages like R, Python, Julia. But Python is definitely not a simple or easy language. I have struggled to teach Python to people because there is no clear conceptual model or is full of inconsistencies. I don’t even agree on its supposed readability. Languages like Julia are built on a few orthogonal concepts that compose beautifully.
That Python (or R) might remain the logical/ better choice due to tooling, ecosystem or simply inertia, is probably true. But this is definitely not due to the merits of these languages {semantics, runtime}.
I am writing some more productive comment on the next post 
.
I have successfully onboarded several people from academia with varying levels of programming skill to the language in a very short amount of time. I started using the language with the release of v1.0.0. These are my observations:
PyCall install packages has resulted on some unreproducible builds for me.I think my biggest problem currently is tooling. There has been a lot of effort spent on interactivity (Plots, publishing systems, etc). Formatting/linting works really well. But things like autocompletion or missing references seem to work in a very inconsistent and unreliable way. I sometimes had a very good experience (specially with small, dependency-light packages), but somehow this degrades in subtle ways until I am again frustrated with the tooling.
Also, I miss the way in which you could inspect an object in Atom 
I know this is not possible in VS Code and inspection is possible through a pane, but still.
I recently looked into Rust Analyzer and really liked how they organize the documentation, for exmaple linking to parts that implement an specific feature: Go-to definition
Perhaps something like creating a roadmap could be useful? I’d be happy to contribute if I knew what/ how / were.
But you can do that with VSCode. In fact I find this one of the most compelling reasons to use VSC as compared to other editors.
But what you quoted is not saying that. It’s talking specifically about how Rust Analyzer organises documentation and links to the code of its different features.
I know that you can navigate code. Well, as long as the exported symbols of a package are not marked as “missing references”, that is.
Brief aside: you might want to look into PythonCall.jl, which gives you more control over your Conda environment.
C / C++ like I can do with MATLAB Coder).Once (1) will be achievable I will probably create my own implementations for my image processing needs so (2) won’t become a deal breaker for me.
This is just an idea (might be a completely stupid one). Just would like to have the view of a more experienced developer.
I might be wrong but the C language is made of ~32 key words. How difficult would it be to give Julia the ability to compile binary from these equivalent 32 julia key words?
One might also have to specify the function argument types and other things…
It’s not so much about the number of keywords but about garbage collection, dynamic code generation, and other things requiring runtime support. For sufficiently restricted subsets of Julia it is already possible (but not very polished) to do static compilation to small binaries. See e.g. Successful Static Compilation of Julia Code for use in Production.
It and StaticTools.jl is getting better, e.g. with adding Bumper.jl as a dependency for fewer memory-handling limitations. I think it might be very usable for many situations already if you can live with the stated limitations. One of is not supporting Windows, which might be fine, but if you want to support all platforms, that’s not possible and I’m puzzled why Windows doesn’t work, since Julia itself is cross-platform. Possibly related to the runtime (since it’s not supported) or compiler supprt, I suppose could be easily fixed, though not sure it’s a priority. Even with it not important for many individual users, knowing I could target all platforms would be a good thing, so I’m curious to know (for sure) why this one limitation.
Coming back to the original question: What I don’t like about the Julia ecosystem is the lack of stability of key packages: Both StaticArrays and Sundials were braking my code twice each in the last years when there was a minor update of the package version number. And Makie has braking changes all the time, but OK, it did not reach version 1.0 yet, so I should have been warned.
On the other hand, managing these problems is doable, by limiting version numbers in Project.toml, writing bug reports and forking packages if required. Much easier than with Python/C++. But there is room for improvements. What I see as weakness is that you need to fork a package to be able to upgrade dependencies of older package versions.
Since the wrapper’s inception around 2014 and all of the things written about it, it has been noted that Sundials.jl only works with Vector{Float64} states. This of course is obvious because of course Sundials is statically compiled C++ which will not specialize on MVectors. The fact that you found out that for a small period of time, some automatic conversions would allow for MVectors to work because it accidentally converted things to Vector{Float64} for you is not “braking my code twice each in the last years”. This is a major case of:
You know it doesn’t compute with static arrays, you know that cannot compute with static arrays, but it still has static arrays, and so the fact that auto-conversions made it work at one point is a bad thing. Our error handling has improved and now it properly tells you that earlier. That is a good thing. We want correct errors. Now change your code to Vector{Float64} if you want to be calling a C library to mutate that object.
I tried that in the past and it caused a 10x slowdown of my code.
You convert in f, which is what it was doing before.