HACKER Q&A
📣 behnamoh

Everyone says Julia is better than Python. When is it not true?


I've been using Python for a while now, but there's a (somewhat elitist) trend that prefers Julia to Python, mainly because of better performance and type classes. I know that Julia still has a long way to go in regards to libraries (compared to Python, at least). But is there something about Julia that is a disadvantage compared to Python? The engineer inside me thinks there's no free lunch, and Julia can't be superior in every way.


  👤 ssivark Accepted Answer ✓
Let me add some nuance to the hype. When someone says “for ML/data science” (just as an example) the common confusion is whether we are referring to researchers & library authors (those who create exciting new capabilities) or library users (most of whom will never release a package of algorithms, but just use available packages). For the former, the Julia experience is absolutely delight in many ways. For the latter, there will typically be a lag in usability (because the former group needs to create the libraries). Julia is somewhere along that curve of transition (remember that Python is older by almost 30 years!), and completeness of libraries might depend on the specific nature of your work. A rough thumb rule: the more algorithmic your work, the more likely the Julia ecosystem already generates value for you. The more plumbing your work is, it might still be a hit or miss, but is improving steadily (but could take up to a decade, to match the maturity of something like Python for the last few use cases).

👤 t-vi
Julia is a great language and has a lot going for it in areas where Python (and the ecosystem) has weaknesses - my favourite are composability (experienced with math libraries) and the ability to reach high speed.

If, on the other hand, you take Python's core strengths like the simplicity, to my mind Julia does not necessarily match these. I have seen people being able to extend Python programs without any Python training or tutorials or even programming affinity just by imitating the code next to where they want the program to do something. I have a hard time imagining that that would be quite as easy with Julia.

Similarly, if you take the ideas from the Zen of Python, you might find that Python (code) fares better on them than Julia.

Now, any of the features that contribute to Julia being more complex in the above sense has a good reason for existing, but there is is value in Python's simplicity that can be easy to overlook.

Of course, one might wonder whether Python started to depart from that - with := and structural pattern matching being examples of things that are valuable features but at the same time adding quite a bit of complexity while being much more controversial than, say, list comprehensions.

Note that this is not about being able to write programs that are easy to understand but about any given code being easy to understand (at the "what does this line of code do" level).

It may also be instructive to compare the (English) Wikipedia entries of both, I think they are to some extend reflections of the different philosophies behind the two languages.


👤 adgjlsfhk1
There are definitely some aspects of Julia that are free lunch. Julia's package manager got to look at what Rust does and some of the pain-points of python's package management, and as a result is much better (think Anaconda, but everything supports it, and with better support for architecture specific binary libraries.

That said there are a lot of places where Julia is a set of carefully considered tradeoffs. For example, eval in Julia always runs in the global scope. This allows the language to run much faster, but isn't always what users expect. Similarly, Jit vs interpreter is a tradeoff. Jit is faster, but has startup lag which means it will often be slower for scripts that take less than a few seconds.


👤 version_five
Julia has some elegant aspects that make it a joy to work with. I'd turn your comment around a little bit though:

> Julia still has a long way to go in regards to libraries

For me, the core practical benefit of python is the ecosystem. I also like the language and there are definitely some intellectually satisfying "pythonic" things you can do. But for work, my core concern is productivity, and python has mature libraries across everything I do (ML / data science) that let me spend my time using it as a tool and not sorting out quirks of the v0.1 libraries.

That's really it. The no fred lunch with Julia is that it's nowhere near the maturity (including documentation) of libraries that python has.