The claim that everything in finance is written in Python is a vast oversimplification. My experience is largely on the sell-side. However, @Pleb seems to agree with my opinion on the buy-side as well.
Low-Level Performance is crucial in real world infrastructure. That's why C/C++ reigns supreme for core functionalities in firms due to its raw speed. Julia may be quick, but its still young and a niche language. It's a lot faster to deploy and easier to write, but if you need a larger pool of experienced programmers, C++ offers a lot more choices.
Bloomberg:
- most is written in C/C++ and some legacy Fortran
C++ is central to how we work at Bloomberg.
the API is written in C++
The derivatives pricing engine DLIB is written in DLIB, which is OCMAL based.
The GUI is written in Javascript
Some stuff is apparently written in Perl
Python seems to have increased in the last decade, but I do think the statement above says it all. Also, even the Python API only works when bundled with the required C++ API.
Blackrock:
- Mostly C++ source
- Alladin was written originally in C++, Java and Perl and has now been updated to Julia.
Jane Street:
Voladynamics:
... should be packaged into an
efficient and easy-to-use C++ library (with higher-level language
wrappers on top).
OneSumX from Wolters Kluwer:
- is written in Java, and any custom function you write needs to be in Java.
Quantlib:
Overall, I do not think the language of choice depends mostly on which one is better. There may be specific topics where one is more suitable than another but that is usually an exception and most casual programmers and users never reach that level anyways. The largest user base of Python users in finance are not developers but guys like me, who are not good at programming but need something that is quick to write and useful. Its also a big plus that Python is also accepted by developers.
Generally, I think you mostly need to use what your boss tells you to use. So far I had the "privilege" to have to use (in no particular order) Python, Java, VBA, Julia, Matlab/Octave, OCAML, BLAN, SQL (DB2 and TSQL, Microsoft SQL Server and Oracle), R, Stata, EViews, SPSS, C, C++ and Javascript for work. Though not programming languages I also needed HTML, CSS, Mathjax and LaTeX.
That said, what your boss tells you to use is similar to actual languages (e.g. all questions must be written in English on Stack Overflow), or social media and the like. A languages success is driven by direct positive externalities, meaning a languages value improves as more users engage and participate with one another. That's why everyone uses WhatsApp.
The community behind Python is honestly second to none. I frequently find myself just blindly typing a question into Google before thinking (e.g. how to define the font in Matplotlib) because SO almost always has the solution readily available anyways. If you look at places like Quora, Reddit and the like you will always find people promoting Python.
Let's look at some data:
- The most loved programming languages in general are supposedly Rust, Elixir, Clojur, Typescript and Julia, according to tag trends on SO.
- Matlab is the least admired language and only 20% of developers who used this language want to use it again next year according to a SO survey
- Julia, according to the same survey is only desired by 2.5%, but admired by 62,77%. It's no secret that I love to use Julia, as most of my answers here utilize Julia. However, I cannot use it much at work because no one else I work with at the moment has ever used it. Forcing people tp use it would just slow down work significantly for some time. Also, it is hard to hire new people with Julia expertise.
- R is only admired by ~ 39%.
I only used Matlab / Octave before I started my career in finance (which is a long time ago). My sister uses it in the automative industry, because the simulink offerings are apparently great in this context. It's mostly network effects again though, with people using it because others use it. I personally never came across someone using Matlab in finance.
It took me 10 years to see a place that uses R. This place used R for some work because the guy building the quant department had a statistics background. They mostly decided to switch to Python (for the stuff they did in R) because it was hard to find people to apply when R was mentioned. Now, whenever some R code needs to be modified, there are only 2 or 3 people left that are willing to do it (and two studied statistics, the other math).
Some more or less plausible arguments against Matlab and R:
Some programmers might say using 1 indexing is why R and Matlab do not work (it's the same argument for Julia).
Neither LSEG (Refinitiv) nor Bloomberg offer direct usage of R or Matlab in their APIs. Provided almost all institutions use either LSEG, Bloomberg, or both, you have a massive problem trying to promote R or Matlab at work.
R is licensed with GPL, as are most packages. As docs.python states,
All Python licenses, unlike the GPL, let you distribute a modified
version without making your changes open source.
This can actually make a difference in a corporate setting, as explained in this R-bloggers comment.
- R syntax is for most, if not all programmers quirky.
Examples where programmers scratch their head (I am by no means a programmer, or a sophisticated R user, it's just stuff that bothers me and I have heard others complain about as well):
In almost all languages, the assigment operator is =, in R it's primarily <- (I think technically there are 5 assigment options in R).
x = "Hello" + "World" in Python vs x <- c("Hello", "World") in R makes you wonder whether <- and c() is designed to make you and your code collapse. Julia actually uses * instead of + for string concatenation. This choice is based on mathematics, because + is usually commutative, meaning A + B == B + A for all matrices A and B of the same shape. * is typically noncommutative and A * B != B * A, just like Hello * World!= World * Hello. While being mathematically sound, most languages, including C++, use +, making this still an interesting choice.
Why does a for loop leave a variable in your environment in R? You usually never need an iterator outside your loop.
It's is trying to make your code work, which is really not useful. How can you column bind vectors of unequal length?
x <- c(1,2)
y <- c(3,4,5,6)
cbind(x,y)
or provide you with a NULL in this case
x <- list(firstname = "AK", lastname = "demy")
x$firstName
I'd much rather get an error than unfortunately using this value elsewhere.
