Convincing physicists that Julia is worth their time and effort


I make presentation about Julia to group of physicists try to show them that Julia is not only awesome, fun, but also worth using. When I ended I put my seminar here, now I need some help.

My audience is mostly differential equations guys, both ordinary and partial, but conservative in very bad sens of the world: they don’t want learn new stuff. If I don’t convince them that they can use they old code in FORTRAN, C and Python code from Julia, I don’t have any chance to achieve anything. Since I don’t use FORTRAN nor C I have no idea, how to show that you Julia integrate good (great?) with them. Can someone can help me with that?

I probably made separate talk on JuliaDiffEq, I’m a fan of this project, but now I must first make this.

PS. GitHub seems to have a bad day, so I have problem with googling materials there.


A fun and quick demo that both demonstrates Julia’s speed and interop is the “Julia Is Fast” notebook in JuliaBox’s tutorial folder. You can find it here:


I prepared/collected resources for a julia workshop for a group of interested physicists recently. It might not be what you need, but you can check it out here:

I didn’t do much on DiffEq but here it is:

Maybe also relevant:


IMO if they don’t want to learn anything new, and would want to use Julia as a wrapper for calling other code, you are just wasting your and their time. Julia has a fantastic DiffEq framework, but it will require learning something new. Pretty pointless to switch to Julia if they don’t intend to use it.


I emphatically disagree with this perspective.

You have to see this from the perspective of a large computational physics or computational chemistry group. Their codes have been developed over many years or even decades. You simply cannot ask an oil tanker to turn on a dime, and reverse direction.

My experience has been that, after first demonstrating the potential for new codes, showing off Julia’s strong interoperability possibilities is the most important aspects in getting these kinds of groups interested and willing to try. One has to offer them a gradual transition. I think the OP is doing exactly the right thing here.


I like your remarks. I agree in 100% that you cannot make this kind of change overnight and gradual transition is most realistic option.

My problem is that in my country, we again stuck with outdated solutions, much below world standards. To choose another example, on my Alma Mater, which is second biggest university in this country, they are saying that is to early to create independent computer science department in 2018!!! They say that good time will be in 2028! To be clear, they have computer science study and hundreds if not thousands of students. I hope that make my feelings more understandable, even if not justified.

And it look like to me, that using Julia they can cut half of the time or more that they spend writing a code, losing 10% of the speed or even less. I think that is bet worth taking.

My English have a lot of limitations, what you mean by interoperability? And what means OP?


Original poster, the person who started the topic. In this case, you.


Ability to call code from other languages.


I truly believe that Julia offers them true advantages over they current methods with it clean syntax, speed and Lisp-like extensibility. I also believe that Julia community, which to me looks still as grossly underpopulated, can benefit from them.

You are absolutely right, using it only as wrapper is down right stupid. I just try to make it as one of my three selling points, in hope that when they start using it as secondary tool, they will understand it can be one of main tools in they toolboxes.


Thank you for information. To this moment I think that it was abbreviation of “chłOPie”, because in polish we often spoke it as “OPie”. “Chłopie” means “the dude” in polish.


I think you make valid points. However, what is often missed in these discussions is that learning and switching to Julia has a cost, which may not justify the benefits that the language offers for a specific person.

In this particular case, we are told that

which I hope is mostly hyperbole (as we are talking about an academic/research environment), but it is perfectly conceivable that some people consider programming a nuisance.

I see three main benefits of Julia:

  1. the language itself is very nice: supports speed and convenience (generic programming) at the same time,
  2. the package ecosystem for differential equations specifically is extremely advanced,
  3. the generic nature of the language allows the use of packages (eg for AD) that integrate well into any task.

(2) yields the most immediate benefits, but would require learning a bit of (1). Until they pay this entry cost, using a new language will be frustrating. Also, they should be prepared to deal with the occasional bug, at least to the extent of making an MWE and opening an issue for the language or a package.

While I am happy when people are switching to Julia, I am wary of overselling it. When this leads to frustration, it may turn people away from Julia in the medium run. I think that people should decide when to try out Julia based on their specific circumstances, and it is perfectly fine to wait a while for the language and the packages to mature.


Not at all. On the contrary - if there is bunch of useful code written by your colleagues it could be stupid to rewrite it with every new language on the horizon.

You could probably find useful examples about interoperability here:

or here:


I completely agree with this sentiment. There is a lot of cool stuff we can show in Julia, but I don’t think the basics are a reason to retool an existing project into Julia. IMO, this is how you get to someone new: you know what methods are at the forefront of their discipline, there is a package for that in Julia, and you explain how it and its surrounding ecosystem can be used to solve these problems in their field.

For ODEs we have things like high order Rosenbrock methods, the ability to autodiff the whole thing, and are coming out with a whole set of exponential integrators. This could improve ODE solving efficiency quite a bit, but is it worth retooling existing code? Probably not. Efficiency is only a reason to switch languages if you’re bound by your code speed and there’s something that can make a massive difference, or if you’re in the rare case where you’re running out of HPC resources because your project is huge.

But for new projects, development time can be cut down quite a bit by using abstract types in the generic integrators to represent the mathematical model without having to hand-code some stiff integrator to work. But ODEs in general aren’t where the huge advantage is. Having easy access to stiff DDE and SDE integrators is uncommon, and mixing discrete stochastic modeling in with that is uncommon. While the existence of these techniques is uncommon, the use of these techniques, particularly in biological and pharmacological modeling, is on the rise, meaning that it may be a particularly good reason to switch to Julia specifically for these tools. In the end, people doing this kind of work will invariably be solving plenty of ODEs as well, probably even more than the specialized problem, and then that is a major incentive to convert and then also move all of one’s new work into Julia.

Other tie-ins to note are things like JuMP, where the first draw is the features (free Hessian autodiffing, the callback structures, etc.) but the lasting draw is the existence of many “only JuMP” optimizers coming out of strong departments like MIT which then bolster the existing work in Julia. It may not be for this audience, but CUDANative/CuArrays is another “switching library” since it allows pretty pervasive GPU use for those who don’t want to or are unable to jump to a lower level for it, while the lasting draw is the efficiency it gives on just simple broadcasted code. While I heavily enjoy libraries like NLsolve.jl, Optim.jl, and IterativeSolvers.jl, they don’t generally have the “newness” to draw a newcommer to the language, but they do give you very good reasons to stay.

Really, language features and small efficiency gains are just things package writers and methods developers care about. Most people are willing to use a package and don’t really care how it got optimized (likely using C++ or Fortran if it’s not Julia). What matters most is what kinds of problems they can solve. If the package choices allow for new research to be done, then they care. If not, they don’t, or they at least care a lot less.


Aj, I gobble word. This should be “using only as wrapper”. Good wrapper is excellent tool.

But thank you for comment, I think I can use it in my presentation.


my JuliaCon was targeting scientists, and I am a physicist so I made it with physicists in mind.

It argues why Julia is most suitable for scientific research. As Chris said, noone should throw away well-developed tools, but Julia allows you to still use them while you can develop new stuff in Julia, and do your scientific work also in Julia.


I make title and abstract to my talk, I will be happy if you say what is wrong, what bad and good and what to change.

Julia. 2010s proposition for scientific (and other) programming

Most of most common used programming languages dated from 1950s to beginning of 1990s. As such they was not designed to used full potentials of today’s computers and don’t benefit from much of development in computer science in last three decades. This talk want to present Julia, one of new languages that try to close that gap, designed for scientific computing. Presentation consisted of both talking and live coding will discus advantages and downsides of using Julia, scientific and not project which use it, touch a problem of its approach to programming and making written code fast.


I think that this is at best a distraction. “Full potential” is misleading, and sounds like you are suggesting that those other languages just utilize 90% of the CPU. Also, while it is a well-designed language, AFAIK developments in computer science per se were not the primarily drivers behind Julia, in the sense of some experimental CS languages that explore an idea.

Depending on how long your talk is, I would focus on a practical demonstration of how parametric types combined with multimethods enable generic programming, in the context of a small example.


You have a good point, I will try to make it better. Maybe you have any sugestion of better starting line?

I already have few examples and I hope that I choose good for generic programming. At least good for now, deadline is comming.


If python has GIL it is not designed well for multi-threading. Means not designed well to using 100% CPU/cores.

So yes - python was not designed to use full potential of today’s multi-core systems.

I think that Kamil wants to say something like that and I don’t think it is necessary to change his words.


[Julia in RMarkdown]

[knitr - other language engines]