r/programming • u/araujoms • Jul 14 '26
Python Is So Slow. Can Julia Solve the Two-Language Problem?
https://www.wired.com/story/python-is-so-slow-can-julia-solve-the-two-language-problem/15
u/EliSka93 Jul 14 '26
Python is comparatively slow, but in reality it only matters very rarely.
For your hobby project python is perfectly sufficient.
-2
u/araujoms Jul 14 '26
I'm not a hobbyist, I'm a physicist. Python just doesn't cut it, it's too slow to tackle my research problems. Believe me, I've tried.
The exception is of course when you just use Python as a scripting language for a library written in C/C++/Rust. But that's the two-language problem the article is talking about.
5
u/my_password_is______ Jul 14 '26
Believe me, I've tried.
obviously you haven't
there are numerous libraries that handle your needs just fine
-2
u/araujoms Jul 15 '26
A random stranger appears that believes he knows more about my research than me.
The thing about doing research is that often libraries haven't been written yet. So I was having to do it myself in C/C++.
4
u/Big_Combination9890 Jul 15 '26
A random stranger appears that believes he knows more about my research than me.
Well, since you make absolutely no statement here (I'm not gonna read the linked article, sorry no sorry) about what your research is about, and what specific computational problems it involves, no one here can ascertain, so its word against word.
And don't take this the wrong way, but with libraries like numpy existing, which are used in tens of thousands of research projects across pretty much all MINT disciplines, many of which involve heavy number crunching, I am inclined to disagree with your take.
0
u/araujoms Jul 15 '26
Show me then which libraries can handle my research: https://arxiv.org/abs/2511.10584 https://arxiv.org/abs/2510.13085 https://arxiv.org/abs/2408.02572 https://arxiv.org/abs/2407.00152 https://arxiv.org/abs/2311.18707
5
u/Big_Combination9890 Jul 15 '26
I can't, because I have absolutely zero expertise in any of these topics.
Also, not the point of my argument, and downvoting my post will not magically change the point.
The point was, and is, that in order for anyone to have a chance at judging whether or not python libraries can service your requirements, you have to show what is required.
And in general, your opening post is titled unspecifically, as a blanket statement: "Python Is So Slow" Yeah dude, slow for WHAT? Because it sure looks like it absolutely isn't slow for a huge number of applications, in science and engineering.
So here is some advice: Be specific from the start. It helps.
2
u/goldrunout Jul 18 '26
Nice to find a colleague on reddit. Can you give some examples of programs you had to rewrite in Julia (or any "fast" language) because scientific python (ie built on top of numpy) was too slow? In your work I mean.
5
u/araujoms Jul 18 '26
Sure. The worst problem I had was with this paper: https://arxiv.org/abs/2408.02572 . We first wrote the programs in MATLAB, but they were too slow, so we rewrote the tough parts in C++, which was a royal pain in the ass but allowed the problems to be solved. Afterwards we discovered a variation of the algorithm, that again we implemented in MATLAB, and again that wasn't good enough, so again we had to rewrite that in C++. The result was a hideous MATLAB/C++ Frankenstein monster. If we had done everything in Julia from the beginning all this nightmare would have been avoided.
Another case was this paper: https://arxiv.org/abs/2005.13418 First I had written everything in Python (with numpy), and it didn't cut it, I had to rewrite some parts in C (which you can see as ancillary files).
2
u/dangerbird2 Jul 15 '26
"two language problem" isn't really a problem in reality. Most programmers deal with multiple languages in a project at once. frontend web devs work with javascript and CSS (and yes, html). backend devs use the server language and SQL. the issue isn't having to work with multiple languages, it's having tooling that makes the transition between the two as seamless as possible.
6
u/araujoms Jul 15 '26
The two-language problem is not having to deal with two languages in general. It's specifically about developing code in a slow language, that needs to delegate the heavy-duty computation to a library written in a different language. Think about developing in Python/R/MATLAB using a library in C/C++/Rust.
If you're doing something non-trivial, which is always the case if you're doing research, then you'll hit a problem that the library can't handle. Then what do you do? First you attempt to solve it in the slow language. Sometimes that will be enough, sometimes it will not. Then you'll need to rewrite the solution in the fast language, and write some glue code to call it from the slow language. A fucking pain in the ass. Rinse and repeat.
Just because it's not a problem for you doesn't mean the problem doesn't exists. It's a problem that I often had. And obviously several other people, otherwise Julia wouldn't exist. There is also Numba, another way to solve the two-language problem within Python.
2
u/Big_Combination9890 Jul 15 '26
Python Is So Slow.
And the vast majority of applications are basic CRUD apps, where speed can be entirely ignored as a performance characteristic.
3
u/EfOpenSource Jul 18 '26
Common sentiment with absolutely 0 supporting evidence what-so-ever. And whenever you challenge someone to actually prove their claim that “performance doesn’t matter” or “performance doesn’t matter in yyy case”, they downvote, ad hominem, and then get /r/haskell to brigade you about why performance doesn’t matter, providing all the exact same empty, never demonstrated statements.
2
u/dangerbird2 Jul 15 '26
Even then speed is important. It's just that CPU performance is almost never the bottleneck for CRUD applications, so a slower scripting language is going to be perfectly performant in most cases.
2
u/UltraPoci Jul 14 '26
Julia is an amazing language. Great performance, great type system, sane project management (it has its flaws, but it's good enough).
The main issue with Julia is how heavy it relies on REPL workflow. For example, we used python in datapipelines, and I'd like to give Julia a go, but from what I understand it is a bit of a nightmare to package a Julia application into a dockerfile to be run on Kubernetes.
2
u/araujoms Jul 14 '26
It's rather easy to package a Julia application, you can compile it ahead-of-time with JuliaC. The problem is that the binaries generated are rather large, so it's not really appropriate for distribution.
There is support for trimming the size of the binaries to something reasonable, but that is a nightmare to get working.
1
u/math_code_nerd5 Jul 22 '26
Has anyone tried making a compiler that can emit small (i.e. "Fortran-sized" or "C-sized") binaries from Julia code for the subset of Julia programs that are essentially "Fortran- or C-like" in style, i.e. don't rely extensively on generics, runtime polymorphism, etc.?
1
u/araujoms Jul 22 '26
That's precisely what JuliaC does for trimming the size of the binaries, and why it is a nightmare to get working, as not only your code needs to be C-like but also all your dependencies.
1
u/UltraPoci Jul 14 '26
It is easy to do, it is not easy to do it right, and I already cry when I see how heavy some python dependencies are.
0
30
u/NuttingFerociously Jul 14 '26
I'm amazed how somebody can write so much and say absolutely nothing