I went to Quakecon this past week and John Carmack made a short appearance on Saturday. As part of this, you could talk with him, ask a question, or get your photo taken.
Some may know that Carmack left Oculus / META a year or two ago to build a company with the goal of producing AGI. Through this process, he has complained a lot on Twitter about how slow Python is… So referencing his complaints, I asked him if he had ever considered using Julia instead or if he was familiar with it.
Good news: He has heard of Julia and often runs into proponents of the language.
Bad news: It seems he’s sticking with Python
The two primary reasons he gave I thought were kind of interesting…
He’s a non-native Python programmer, and thus, the breadth of the Python ecosystem / community is hugely helpful
The slowness of Python is less of a big deal when he can spin up a 128 core server to speed up execution by brute-force
TBH the answer regarding brute-forcing Python to a speedy execution kind of surprised me, given how well optimized the id Tech game engines were. (Yes, I suppose something could still be well optimized and slow.)
Coming out of this, I wonder what effort could be made to better show the breadth and depth of our own ecosystem to non-current users of Julia? Things like JuliaCon are a good start, but my hunch would be all those partaking are already existing users of the language.
I don’t get this, if you run Julia say 100x faster than Python, you can ALSO spin up parallel machines but then get 100x as much done as 128 core python.
Yeah, I agree. The answer struck me as a bit odd, especially for someone that [seems] to have cared for optimization so much in the past.
Perhaps for the work he is doing, the practical difference from moving from Python to Julia is not worth it. Julia could have a 90% improvement in speed, but if that really only means you’re waiting 10 or 20 more seconds for execution, then maybe it makes sense.
I think this remark from another thread is relevant:
If most the execution time takes place in kernels written in a fast language, then Julia is likely not anywhere near 100x faster. In fact, if those kernels happen to be more optimized, then the Julia version might be slower.
The true answer is probably unfortunately that Tech industry is mostly grift these days and Carmack is just a big name they can used to attract money. Particularly if the goal is “artificial general intelligence” which is certainly a huge grift target at the moment.
I don’t really see a contradiction anywhere. It can be the case that it is annoying that python is slow (and thus worth complaining about) while at the same time it isn’t so bad that it is worth the drawbacks of using a different language (e.g. since fast libraries can mitigate the issue to some extent).
I also don’t really see a connection to griftiness. Big python is paying him off?
He mentioned to me specifically how slow looping is in Python so I suspect he’s writing a lot of pure Python and/or not using packages where Python is simply a wrapper for C++ under the hood
I don’t really want to focus on griftiness, though I think it’s everywhere in tech and has been for a while. The point I was making is if you don’t really have a real product and there’s no real intention to create a product then it doesn’t really matter how fast your product is.
Hey, not really related to the content of this discussion per se, but I just wanted to applaud what sounds like a really wholesome and productive interaction between different communities here with John Carmack! This is truly what I love about the Julia community in that we can bridge between and have conversations with different communities.
Anyhow, just wanted to share my happiness on this front – keep disussing!
I’m sure I have heard GVR say stuff like this in a few places, such as this linkthat has lots of annoying ads but contains the quote.
The slowness of Python loops and recoding things in C/C++ was something that GVR planned on happening in the community. If your slow Python code bothers you, find the slow part and make it C. The two-language problem kicks in when you realize that you aren’t a good C/C++ programmer and don’t want to learn the C API of Python.
The Julia answer is, apparently, take your slow, memory hog code and post it on Discourse , so you can learn about all of the hard work that the Julia universe has put into being fast but easy to use, and appreciate the elegance of it all.
I think it’s actually possible to reconcile all of these things pretty easily with some assumptions I would make from my limited interactions with John:
John has an aesthetic/moral revulsion to design decisions in programming languages that don’t make sense to him. (As a comparison, note that he once described Rust using the moralized term, “wholesome”.)
John also has a very clear pragmatic/factual sense that (1) is not a very relevant issue for his work.
For someone well versed in a fast statically compiled language, they just need a language to quickly string together the underlying components. Python fits that description pretty well, especially since other people have already bound their native code to Python as well, hence the ecosystem point.
I use a different argument in favor of Julia in this situation. I point out that Julia makes it very easy to build performant bindings in Julia itself. ccall is very efficient, especially over Python’s ctypes. I also find it much easier to just use Julia for everything rather having to setup Cython. This is actually the main thing that turned Julia from a hobby to a language I use professionally.
, so you can learn about all of the hard work that the Julia universe has put into being fast but easy to use, and appreciate the elegance of it all.