Hacker News Reader

> I’ve read some Julia source and its an awful experience trying to figure out what method is actually going to get executed because of multiple dispatch.

This is the purpose of the @which macro:

    julia> @which diag(randn(3,3))
    diag(A::AbstractMatrix) in LinearAlgebra at /opt/julia1.7.2/share/julia/stdlib/v1.7/LinearAlgebra/src/dense.jl:249

It gives you filename, line number and function signature.

> I don’t think Python will ever be half as fast as the fastest Julia programs, but that’s okay. A hell of a lot more games/products/everything has been shipped with it than ever will be with Julia 1.*

Because python is at least 3 decades old and julia is just a decade old. even python has a "hate" phase before it got widely adopted.

> With Julia, I have to think multiplicatively about every call site because it could get called with a million different methods. It’s so annoying.

whut?? are you saying this just to sound cool? because for me this is hilarious.

Well for me, I have 30+ years of software engineering for billion dollar companies to look back on.

Pardon me if I don’t find your input valuable. I’ll check back with you in twenty years to see if you matter. ;)

I’m not sure what you mean by “sound cool” but you have a lot to learn. Julia’s types are not like templates or generics in other languages, they can basically fit into any method-shaped hole. So, at a call site, there’s no way for me to intuitively reason about the data at play, because some_method() can be literally anything. Combine that with a lack of interfaces, and it’s just mangled up code all over the place.

I’ve worked on codebases that stretch longer than my working career, I’ve worked on code where 100+ PhDs had left their mark in gnarly R/Matlab voodoo, I’ve worked on code that transacts hundreds of billions of tax dollars in a year, and much more.

Julia is a specialized tool for HPC, and the illusion that multiple dispatch without interfaces can be used to build reliable, understandable, engineerable systems will die as surely as the sun sets each night.

I’m not sure your background, and maybe HPC is your expertise or whatever. It seems like you need some better coworkers to learn from, or at least more variety in your intellectual diet.

While I think I can see where you're coming from, I will say as a personal anecdote that at this point I do feel that I can intuitively reason about the data at play quite easily, and no longer ever find myself running into any confusion about which method will be called (I don't think I've even had to check my intuition on this point with `@which` in over a year) -- but it did take me about two solid years of using Julia for a serious part of my time to get here.

It is, in my view, a fundamentally different programming paradigm that most of us have no previous built-up intuition for (unless perhaps you have spent lot of time with languages like Dylan or perhaps CLOS). But it is something you can learn and develop intuition for like anything else.

For those still learning, I may also mention `@edit`, which will not just show you the method, but take you directly to the source code of the method being called -- which is something that remains quite useful even when your intuition is fully-developed.

> I’ve read some Julia source and its an awful experience trying to figure out what method is actually going to get executed because of multiple dispatch.

I totally get where you're coming from, as this is how I felt when I started out exploring Julia code. In previous languages, I preferred to use the simple tools I was familiar with (my editor and ack/ag/rg) to explore code, but that workflow was a frustrating no-go in Julia. The usual alternative in those languages was to change my entire coding experience with an IDE, or to accept some (slight) additional complexity with things like ctags. In Julia, neither of those is necessary, as the inbuilt tools like @which, @edit, methods(), and methodswith() do a good job of providing a non-intrusive, simple alternate set of tools. (Shoutout to the InteractiveCodeSearch.jl package too, which provides a nice interactive interface over these that sometimes comes in handy.)

Now, generated functions and @eval-ed functions, those are a bane of readability when you're new to the code. Thankfully, those are rare enough and usually in deep enough parts of the code that this does not pose a significant problem.

[1] https://github.com/tkf/InteractiveCodeSearch.jl/

> I don’t need interfaces in Python because I can just write or extend a class.

Which is strictly less powerful than creating a subtype...

> Multiple dispatch is a bad fit for most problems. It’s the hard truth many Julia users won’t swallow because LLVM can give them such good performance with such low programmer effort.

what is this claim based on? hearsay?

> I’ve read some Julia source and its an awful experience trying to figure out what method is actually going to get executed because of multiple dispatch.

how is that difficult? you need to elaborate on that because having to "figure out" means you didn't really use Julia enough