I was pleasantly surprised today to see a short feature on Julia in Nature, one of the most prestigious scientific journals in the world.
Web version:
https://www.nature.com/articles/d41586-019-02310-3
PDF:
I don’t know if the Nature editors came up with the idea for the article themselves or if someone in the Julia community gave them a nudge. If it’s the latter then congratulations, because this is basically the best two-page ad you can buy in academia.
for what i saw in slack, effectively it’s from Nature’s editors 
This is really big. I honestly hope the scientific community picks up more on this amazing language after this blog post. I’ve been trying to convince colleagues that Julia is worth a try for more than a year now.
I am very happy to see Julia mentioned in Nature, but I wonder if the article is creating inflated expectations.
All those blurbs from various users can be read as implying that Julia somehow magically gives you Fortran speeds while you can keep programming like in Python. This is (unfortunately? fortunately? 
) not true; to write fast programs in Julia one has to use it idiomatically, which takes a bit of time and effort to learn. Only the last quote (from Frank Giraldo) conveys this message:
You have to suck it up and just dive in. It’s not really that difficult.
Also, while in nitpicking mode,
multiple dispatch (allowing multiple functions to have the same name) and metaprogramming (programs that can modify themselves)
are inaccurate, and probably sound a bit weird to scientists unfamiliar with the concepts.
I agree that this kind of promotional piece can hurt in the end. For now it’s hopefully going to create a lot of awareness of julia in the scientific community. Should be a good thing overall. The tone of the article though is a little like: just look at the keyboard and julia will write the code you intended. 
All in all I’m happy to see julia get some well deserved attention. 
I also agree, it could create high expectations that sets new comers up for disappointment, Julia can be (is) really frustrating if you come from a MATLAB background, and I know of other academics who tired to translate their code and gave up because it wasn’t as straightforward as promised. I’m glad I persevered, but I’m fairly hard headed . If you are short of time and expect to easily write like MATLAB or python, you’ll be disappointed. I persevered because I think it is the language of the future, and I think this article will make more aware of Julia as an option.
I’d love to know how they got that article in Nature!
To quote from the article:
A lot of people, when they hear ‘Fortran’, are like, ‘Oh, my God, I don’t want to program in that.
At some point you will need to answer the question what you value more, performance or readability (to some extent also in Julia 
). I personally think much of the criticism towards Fortran originates from the fact that it’s traditional field of application has a strong focus on performance, which combined with a lack of decent software design inevitably results in ugly code.
In defence of Frank Giraldo (they’re doing incredibly great work over at CLIMA and contribute a lot to the Julia ecosystem), I point out that HPC and climate modelling are still dominated by Fortran and C-ish languages. What people coming from Matlab and Python often neglect is that performance has extremely high value in that field. While the situation is changing, receiving funding to implement stuff in non-standard languages, is still not easy and you need to justify for that. I think the goal of his statements is to make clear, that you can get really good performance with Julia while retaining nice and readable code. It’s not dead simple but it’s also not overly hard, especially when compared to traditional languages.
Some time ago I also implemented an unstructured 3D MPI-parallel discontinuous Galerkin solver for Navier-Stokes derived from the DG solver Flexi. “Surprisingly”, performance was not simply miraculously available for off the shelf code, you really need to embrace Julia, for performance of the same order of magnitude as Fortran and C++ in a complex code base. The first trivial thing is that you’re lost once you need the GC. What was frustrating however is that I sometimes found myself writing code which was unnecessarily ugly and un-Julian to squeeze out the last couple of percent for some critical code paths. I think that this situation will or has already improved in newer Julia versions and a more mature ecosystem (or with improved personal skills). Despite this criticism the code of the solver was significantly shorter, more readable, maintainable and extendable compared to a similar Fortran version.
This might have contributed to some uptick in search activity In August: https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=%2Fm%2F0j3djl7
I find that allocating an occasional large array or similar is fine, it is many small allocations that kill performance. So for mid-level code and up, it is fine to rely on the GC. Also, I think that the compiler is getting more and more clever about making temporary allocations (in particular, current master/1.3). YMMV.