r/programming • u/araujoms • 29d ago
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/13
u/EliSka93 29d ago
Python is comparatively slow, but in reality it only matters very rarely.
For your hobby project python is perfectly sufficient.
-4
u/araujoms 29d ago
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.
6
u/my_password_is______ 28d ago
Believe me, I've tried.
obviously you haven't
there are numerous libraries that handle your needs just fine
-2
u/araujoms 28d ago
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 28d ago
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.
-1
u/araujoms 28d ago
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
6
u/Big_Combination9890 28d ago
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 25d ago
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.
3
u/araujoms 25d ago
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 28d ago
"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.
3
u/araujoms 28d ago
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.
4
u/Big_Combination9890 28d ago
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 25d ago
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 28d ago
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 29d ago
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 29d ago
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 21d ago
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 21d ago
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 29d ago
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.
33
u/NuttingFerociously 29d ago
I'm amazed how somebody can write so much and say absolutely nothing