loladiro

Yes, happens all the time, but Julia has been public for 8 years now, so that's not thaaaaat unreasonable. The funny ones are the "15 years of Julia experience" ones.

I think this has been completely achieved and we're trying to go beyond into things that aren't easily possible in either language. On the performance side, there is a certain level of performance that a language needs to have for it to be "fast" (which C and Julia have, but vanilla Python does not), but beyond that other things become more important for absolute performance. Those are things like memory layout, parallelism, algorithmic selection (ideally with automatic specialization to the particular problem). There are systems in limited domains that have all these features to achieve the extra performance (e.g. all the machine learning frameworks to this kind of stuff), but I would like to find ways to make these capabilities more generally available, so I think that's the frontier on the performance side.

On the simplicity side, obviously more capabilities bring some additional complexity, but I think something that Julia has always done well and that is extremely important to us is to start simple and have everything complicated be optional, so if you just want to get things done, or use it as a calculator you can. Only if you need to do something more complicated should you have to reach for the more complicated tools. I was discussing this approach with Chris Lattner (author of Swift) a few years ago over dinner and he called it the "Principle of Gradual Exposure of Complexity", which I think is a good term for it and one of the key things we're trying to do.

Programming languages translate between something the user understands and something the machine understands. The language determines how sophisticated that translation is. For example, the programmer may write `a + b`, and the machine will go off and do things. Now the difference between static dispatch, single dispatch and multiple dispatch is basically the following: If the language always tries to do the same thing, no matter what `a` and `b` are, that's static dispatch. If the machine looks at what `a` is to decide what to do, that's single dispatch, and if the machine looks at both `a` and `b` that's multiple dispatch. There's many reasons multiple dispatch is useful, but one of the primary ones is that it allows easy extensibility. Suppose you have two people, one working with cats, one working with dogs.

The cat person might write:

meet(a::Cat, b::Cat) = meow()

the dog person might write

meet(a::Dog, b::Dog) = sniff()

but what if you're neither of those people, but you got a dog from one and a cat from the other. In a single dispatch system, you'd have to go talk to the cat and the dog person and get them to change their code to something like:

meet(a::Cat, b) = if isa(b, Cat); meow(); elseif isa(b, Dog); growl(); else; error(); end

and similarly to the dog person.

In a multiple dispatch system, you don't have to go to either person, and you can just say:

meet(a::Cat, b::Dog) = growl()

There's lot of nuance here, but that's the basic idea. When I say "go to", I here I may or may not mean "go talk to". Sometimes it's a question of how you organize your code, sometimes it's literally a different person writing different code. It may sound a bit abstract, but the practical effect of being able to express things cleaner is really quite profound. Also of course in reality, the objects of interest aren't cats and dogs, but complicated matrix types, or equations, or weird number types or neural networks, or something like that, but the core problem remains. You don't want the person working on neural networks to also have to know about quaternions, but you may want to put quaternions in your neural network. The expression problem (https://en.wikipedia.org/wiki/Expression_problem) is the technical term of this extensibility difficulty.

A lot of languages offer multiple dispatch as an optional feature, but very few languages rely on multiple dispatch as their core paradigm. The language that previously came closest was probably Dylan. The problem with multiple dispatch is that it is really, really hard to optimize well, so I think in languages where it is optional, you tend to run into a bit of a chicken-and-egg problem. Because the mechanism isn't super fast, people don't use it and because people don't use it, nobody bothers to go optimize it. That said, though, the design goal of Julia was not primarily to write a multiple dispatch language, it was to write a language that would be really good for computational science. Multiple dispatch just happens to be a paradigm that works well for that domain (because you need to work with lots of weird and complicated abstractions - numbers, arrays, devices, data structures - and compose them in complicated ways. Multiple dispatch gives you a good way to structure that. I think it would be fair to say that we were surprised how well multiple dispatch as a paradigm actually works when optimized well. We knew it would be nice, but it has turned out to be absolutely critical.

1. Hmm, I'm not sure. In some respect, I don't feel the Julia 1.0 compatibility constraint, because there's always 2.0, so anything I want to change, I can just plan for now and we'll get around to eventually. I talked a bit about things I'd like to change here: https://www.reddit.com/r/IAmA/comments/hyva5n/we_are_the_creators_of_the_julia_programming/fzf3zni?utm_source=share&utm_medium=web2x
2. Custom Compiler passes that allow you to make domain specific optimizations for your particular application. I think that could be huge and we could do really well at it.
3. The canonical answer to static compilation requests is https://github.com/JuliaLang/PackageCompiler.jl. It's not quite there yet and we need to do some work to streamline it, but it does basically work.