The Julia Programming Language
9 HN recommenders · recommended in 14 months, 2019–2025
35:24 · 79K views · Jul 25, 2019
Julia co-creator Stefan Karpinski explains why multiple dispatch makes Julia code and types reusable across packages with so little friction. He covers sharing basic types and sharing generic algorithms.
HN commenters recommend it as the definitive explanation, from a language designer, of why multiple dispatch makes Julia's composability work.
20 comments from Hacker News
Did you mean "unreasonable effectiveness"? :P I just watched that talk the other day, and boy is it insightful. Julia has cracked a fairly magical combination of features. I fully expect it to replace Python over the next 10 years. Direct link to "Unreasonable Effectiveness": this video
It's hard to say limited benefit when the entire Julia ecosystem evolved to so heavily rely on it, to allow for each package to work on it's own level of abstraction: For example, the Julia's standard library implements all of the basic math operators on the CPU, and libraries like Flux then define it's own methods to implement the higher level operators used in ML (such as convolutional layers and activation functions). And then someone writes those same basic math operators but instead of running on CPU they run on GPU, and for that they use a new type (CUArray). The original library knows nothing about CUArrays, it will call the same basic operators as always, but since they have a different type (received from the user) they'll dispatch to the GPU version. This kind of interaction can grow indefinitely, for example if you use a complex number type/library it will change the basic operators to deal with both real and imaginary parts, and if you use the GPU types within it, then it will do complex math in the GPU (and ML on complex math on GPU..., without any of the libraries being aware of the other). You can see a more detailed explanation on: this video
The core problem with class-based object orientation is that methods go inside of the type instead of being added externally. That means everyone has to agree on what methods can be called on a class or they have to subtype it, which sounds harmless, but is actually a big problem when what you really wanted to do was just define a new method for an existing type. My best attempt at explaining: this video There's also the issue that one sometimes needs to specialize generic operations in generic algorithms on something other than the receiver—sometimes even on more than one of the arguments. Single dispatch forces you to use something slow and awkward like double dispatch in cases like this. And that's assuming the person who wrote the generic code anticipates the need for specialization! If they don't allow for it, then you're just stuck. With multiple dispatch, you can just define the method you need the specialization for and you're done.
"The Unreasonable Effectiveness of X" is a reference to the well-known 'the unreasonable effectiveness of mathematics in the natural sciences'. It's turned into some sort of meme. Maybe you've seen 'the unreasonable effectiveness of recurrent neural networks' before. What you were referring to is a talk by a core developer at JuliaCon 2019 titled 'The unreasonable effectiveness of multiple dispatch' [1], which has less of a fanboy-vibe imho. Edit: Oh. I didn't notice the arstechnica article had this exact title. That's a bit cheap... [1] this video
What? I used to write python, and to me, MD is first and foremost a conceptual improvement. Makes writing code so much sweeter, more expressive and sensical. It also heavily improves composability. It's LESS performant if not done carefully. Certainly FastAI, Matt rocklin etc didn't reimplement a subset in python just to get slower code See this video