Why is Julia so great?

I first come to this forum in 2022 and amazed by the enthusiasts and responds of almost all my questions are being answered.

You can read the wikipedia and the Notable Uses of Julia:

    The Federal Reserve Bank of New York builds macroeconomic models in Julia in 2015 (ported from MATLAB), and for estimating COVID-19 shocks in 2021[166]

    BlackRock, the world's largest asset manager, for financial time series analysis[167]

    Aviva, the UK's largest general insurer, for actuarial calculations[167]

    Mitre Corporation, for verification of published election results[168]

    Nobel laureate Thomas J. Sargent, for macroeconometric modeling[169]

I combine Julia with Python sometimes while learning Calculus for Undergraduate (till today), but Python code can be executed in Julia with PyCall…

Open source is the great advantage here, since MATLAB is expensive. C and Fortran has the highest speed but you need to code longer in order to gain the same output. We will still need C and Fortran as the bottom of food chain.

I installed MATLAB and never open it again after busy with Julia. Some output that I want are not yet available or can be achieved in Julia thus I use Python. For example to create Riemann Sum animation.

I think just read the wikipedia show it to yourself, if NASA uses it, and you have interest the same as NASA then you probably will try to use JULIA. or perhaps you have interest the same as Federal Reserve and they use Julia too, so you are curious and want to learn what Federal Reserve do with Julia? To print more money and make dollar weaker than CNY?

This talk might suit you or, whole or pieces. It focuses on ground-up Julia programming and how Julia has the dynamism of Python, the numerics of Matlab, and the speed of C, C++, and Fortran. There’s a benchmark of a 1d PDE algorithm coded in C, C++, Fortran, Matlab, Python, and Julia, with comparisons in run-time speed and line count.

It likely needs updating to Julia 1.8, and the PDE benchmark is perhaps not as dramatic as it could be, since the dominant cost of the FFT is the same in all languages. But I’ve found that scientific programming people who struggle daily with C/Fortran and R/Python/Matlab react with “OMG, Julia looks amazing.”


I gave a talk pitching Julia to my community (quantitative ecologists and fisheries scientists, mostly users or R and ADMB/TMB) a couple of years ago that you could look to for inspiration. It got a good response, generated some interest, and earned me a reputation as “the Julia guy,” but I don’t know of anyone who has switched since then.

There are a lot of great reasons to use Julia, but most people will not be motivated to learn a new language until they see a really compelling tool or application that would make their life genuinely easier, but isn’t available in their current language. There’s no harm in giving a presentation to let people know about Julia and its advantages, just be patient and understanding of why people use the tools they do.


I was first interested by Julia a few years ago because I spend (waste) a lot of time fighting the two-language problem. At that time, I was working on a large scale simulation software where two sub-teams (pythonistas vs C++ gurus) collaborate. The two language interface was a nightmare (partly due to technical issues but mostly with political issues (where the language boundary should be placed)).

It was immediately clear to me that Julia would solve this problem being a way more productive solution.
Unfortunately, Julia was considered too immature at that time and was not accepted. Fortunately, I have completed many new projects in Julia since then with a great productivity !

I only code in C++ when this is a strong client’s requirement and I always have the feeling that I have to put a very heavy and uncomfortable armor to start working…


Yes, I should have written “tool, application, or use case.” For anyone developing performance-critical code, avoiding the two-language problem may be enough motivation by itself.

1 Like

To me, the best feature of Julia is its composability which allows to achieve substantial functionality with very little code. Here, generic functions throughout the language, i.e., without any of the compromises/restrictions in other languages, really shines and often allows to split code into separate and orthogonal parts which can then be freely combined. Just to illustrate …

using MonteCarloMeasurements
using DifferentialEquations
using Plots
sol = solve(ODEProblem((u,p,t) -> - u .* p, [1.0 ± 0.1], (0, 10), 0.9 ± 0.1), Tsit5())

I pitched Julia to colleagues more than a year ago and approached it more from a holistic point of view and I’ll have to echo those in this thread that say it is more useful and worth other people’s time if it is presented in a way that shows how it can solve the problems they/the team faces in a clearly better or more elegant way. This latter method is how I got some people to start using the language.

It’s less useful to give general remarks about the language like its number of packages, or go into abstract concepts like multiple dispatch, because most people just don’t care. I wouldn’t even go into any benchmarks either, even if they are rigorous. Let them discover for themselves how fast it can be, because not everyone cares about performance and the people who do will quickly figure it out (there is no shortage of optimizing code examples here). Finally, the audience will be different between e.g. software and electrical engineers and between Python and Fortran or C++ users, in part because they’ll complain about different aspects of the language. A Python user will probably be more interested in mitigating compiler latency and a Fortran user will probably be more interested in tools for parallelization and standalone executables. Describing how to mitigate these concerns will be different for the two because the workflow in Julia is opinionated.


I guess I’m lucky that I’m the head of the data science department in a small financial institution. I built the team from scratch, and from day one I said we’re using Julia and that’s that. It’s been 3.5 years and we’ve never looked back.

Julia & ecosystem solved all of the problems in my domain easily, clear compact code, blazing speed. For fun we tried the same problems with Python and R, and the experience wasn’t even close in terms of personal productivity (how quick & easy it is to write clean correct code, small and large scale) and execution speed (we can’t take two steps away from our chair before Julia is done; we can take a long stroll around the office, socialize with people, come back and Python & R would still be chugging away, the meme of “it’s compiling…” comes to mind). People are genuinely happy to use Julia once they “get the hang of it” as none of them knew Julia when hired, now I can’t take Julia out of their hands.

Nothing beats actually using it to solve real world problems. If the tools for your domain are mature enough, don’t talk about it, just do it and show people. Using it is a transformative experience, there’s no going back. This speaks louder than any sales pitch.


I also tried to pitch Julia at my university at some point and it didn’t work. People (psychologists / neuroscientists) didn’t care about multiple dispatch or types or broadcasting at all, and only asked “does this have better libraries for our use cases than Matlab or Python” for which the answer was no. What I only realized later was, had I convinced anyone to switch at that point, I’d have been on the hook if anything didn’t work because people would have thought I promised too much. Which was not my intent, I just wished I could collaborate with others on Julia stuff around me. So, like the others in this thread, I can only advise not trying to “sell” Julia and instead be an example that others naturally want to emulate because you have an easier time getting your stuff done than your colleagues. If you can’t do that then your colleagues are probably right to stick with their established tools :wink:


I made a blog post on the topic you might find interesting: What's great about Julia?


Was this topic already cited here yet?

Something that has not been said in the previous posts: if it is a research institution, replicability is a must, and thanks to Pkg3 the way you add packages and the full stack of underlying dependences get automatically recorded in a small Project/Manifest.toml files and this makes so easy to replicate by anyone (you included 10 years later) with just a Pkg.activate(...); Pkg.instantiate();. This is awesome from my point of view!


Honestly, I give weird looks when anyone under 40 says they use MATLAB, and I liked that language. I suffered through Python and my requirements to prefix anything good with np.(…), but had much better syntax for things elsewhere. Julia on the other hand fixed every single thing I hated about MATLAB and kept everything I liked about Python without introducing anything I found annoying, moreover its fast. It’s better than MATLAB in every way that mattered to me.

  1. I don’t have to do weird things to make my code fast, and I can have pretty low-level control over things without sacrificing speed
  2. Julia, like Python uses square brackets for indexing, round for function calls
  3. Julia, like Python has a readable way to introduce keyword arugments. Deciphering long lists of keyword arguments in MATLAB is a special kind of hell.
  4. With Julia, putting a project together with multiple files is a transparent, intuitive, and controllable process
  5. Lots of syntactic sugar to make things terse and readable. M-I works, instead of something dumb like M - eye(length(M)) with no additional memory allocated. So does X .- mean(X,dims=2). Thank you.

I could easily write a 50-item list of stuff like this. They key takeaway for me is that after using Julia for 2 years, I was more than 3x as productive as I was with MATLAB after using it for 6 years. At this point, I consider Julia an unfair advantage.


I think the Julia community is wonderful.

As a new commer to Julia I often ask questions that, after reading the answer, are near obvious. But I always get quick and clear answers.

I came to Julia because I was forced to. I never regretted that.

The language is very powerful and will require more training than C or Python. But it is worth it in my case. I don’t onlly use packages, I create my own code to solve my problem with my algorithms. With Python, I would have to get back to C++ to get reasonnable performance and then integrate into Python. That’s not very efficient.


My last comment was more of a “Julia vs MATLAB”, spiel and why Julia fixes everything that annoyed me about MATLAB, but I didn’t have much time to go into why I enjoyed Julia more than Python. I started out with MATLAB and when I got a job, moved on to Python because I worked for a small company that didn’t have a MATLAB budget. Python is a great tool if all you’re doing is black-box modelling. These models take standard forms that are easy to compile.

The problem is that in my field, Process Engineering, data is often too boring to build useful black box models unless you run expensive experiments. Fortunately, there’s a wealth of knowledge on how these process actually work, so you can get much further by combining machine learning with first principles and simulation.

Simulation is where Python’s environment is sorely lacking, and it’s still fairly behind MATLAB/Simulink. However, in my opinion, Julia is actually ahead of MATLAB/Simulink with respect to simulation, at least in terms of being able to build your own models (ModellingToolkit.jl is amazing and free, but if you want more convenience you can pay for JuliaSim). On top of simulation though, Julia also has really flexible and composable machine learning capabilities with Flux.jl and Optim.jl. It’s really easy to train a small neural network with the L-BFGS algorithm to get much faster convergence than common Neural Net optimizers. In engineering, black box modelling is often not good enough on its own, which is why people who stick to the Python environment can’t break out of a very small problem set these techniques work for. The data never tells you everything you need for prediction; you need to combine machine learning with simulation in elegant ways. Nothing does this better than the Julia ecosystem.


Maybe one thing that you can consider is not only “why people should give it a try” but also the opposite - what are the hurdles that may stop people from doing so.

You probably know the “main language” in your field but can look in the fields of your audience in the talk. For example, my research field applied macroeconomics, particularly Bayesian Econometrics and like 90% of the codes of papers that get published in the good journals are in Matlab. So if I want to integrate the latest and the greatest from the research in my work I either have to translate thousands of lines of code or just build on top of the others (the standing on the shoulders of giants). If we get a new PhD at our institution that wants to work in this field they have to, more or less, learn matlab. Maybe look around if there are julia codes in the fields of others that might help.

Building on that it would be great if you can find particular applications (w.r.t. the people in the audience) where Julia’s strengths are highlighted. For example I am still struggling and constantly abandon the language because I cannot find an instance where Julia is better for me and my particular codes are always slower than comparable matlab codes. In some instances it was actually non-language related (I have touched on this here). In any case switching to any new programming language is extremely costly, so it has to be very, very well justified.


I did the same at the company where I work, and many people had positive reactions, including management who clearly saw the value in Julia for prototyping new ideas, but not to replace C in production code. My presentation included a benchmark of fast Hadamard transforms implemented in Julia, Python and C. The implementation of the fast Hadamard transform relies on divide and conquer, which is ideal to showcase the superiority of Julia over Python as Python is really slow with recursive algorithms. Julia was 150X faster than Python and 1.5X slower than C. I showed tricks to interface Julia, Python and C as well as general performance tips. If you’re interested, I can share my slides in a private message. Let me know.


Hello @nvenkov1 Yes the presentation would help a lot (redacted—you can DM).

Ah, IPGP. It’s sure full of GMTeers (I’m an ancient IPGPeer too). The seis supplement started there

And in case you haven’t seen this and this

1 Like

I gave a similar talk to a computational physics community recently. There are some gems in this thread that might be of interest to you:
Seven lines of Julia