Absolutely and there is nothing wrong with that. But over the decades I have followed computing I have seen languages with much smaller advantage relative to the competition than Julia rise to prominence.
But I am also pretty sure that whatever replaces Julia in the future, it will have borrowed heavily from Julia in terms of semantics, syntax, libraries etc. Multiple-dispatch that Julia pioneered is almost certainly going to dominate future languages.
This is in similar ways to have functional programming has entered almost every mainstream language and OOP entered almost every language before that.
AFAIK, it was Lisp that pioneered multiple dispatch. It hasn't “dominated” a substantial number of languages since then. Maybe the problems it solves haven't been seen as important enough? I really don't know, it seems such a logical extension of the single dispatch known from many OOP languages.
Arguably it may also be because without JAOT compilation as in Julia, multiple dispatch normally comes with a significant runtime performance cost, as far as I understand.
I'm not aware of any that had the sort of complementary designs between the compilation model and multiple dispatch. E.g. in Common Lisp, two of the most important functions for multiple dispatch, addition and multiplication aren't generic functions and need to be shadowed and replaced by generic functions if you want multiple dispatch. My understanding is that they did this for performance reasons, but julia doesn't have any performance degradation from making literally everything other than like 5 builtins generic functions because of the way it's compilation model dovetails with multiple dispatch.
I just checked in my repl and in my current session with a few packages loaded, + has 195 methods defined on it and * has 347 methods. If you look at https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_pract... they present some evidence that multiple dispatch sees far more use in julia than other languages.
> need to be shadowed and replaced by generic functions if you want multiple dispatch.
yeah, but there are extensions for some Common Lisp implementations which would allow that with reasonable speed. I've seen a bunch of CLOS extensions in recent years in that direction.
> ulia doesn't have any performance degradation
Common Lisp generally has a different generic function model from Julia. It's extremely dynamic with an optional meta-object system. Thus its use case is different. But: for example a CLOS-based CAD system might use generic functions everywhere and needs the respective performance for that.
> I just checked in my repl and in my current session with a few packages loaded, + has 195 methods defined on it and * has 347 methods.
In CLOS one would not like that design. Though there also might be generic functions with many methods. My default CL has for example 84 print-object methods, some might have hundreds. Though generally it is not seen as desirable to group semantically very different operations under one name - especially given that CLOS provides different types of method combinations and a CLOS generic function might create a more complex interface.
CLOS has before, after, around and primary methods for a default method combination. One can write arbitrary new combinations and have different ways to dispatch, different inheritance strategies, etc. Thus its optimization problems to provide faster dispatch is different from what Julia wants to address.
Dylan then for example had to address the 'generic function everywhere' problem. There binary+ is a generic function.
> In CLOS one would not like that design. Though there also might be generic functions with many methods. My default CL has for example 84 print-object methods, some might have hundreds. Though generally it is not seen as desirable to group semantically very different operations under one name - especially given that CLOS provides different types of method combinations and a CLOS generic function might create a more complex interface.
Totally agreed here. However, addition, multiplication and so on have a very uniform and well defined set of semantics that apply to many types from all the various representations of real and complex numbers to the many many different types of matrices in Julia's LinearAlgebra library (lots of wrappers for things like Symmetric, or Tridiagonal matrices, lazy matrix factorization objects, adjoint matrices, etc.)
That's why there's so many methods on addition and multiplication in julia, and why I found it so surprising that CL doesn't do this on purpose. But I get that scientific computing isn't as big a part of the demographics in the CL community so I guess it makes sense.
a bunch of languages (incl. Julia) has been influenced by CLOS' multiple dispatch (Fortress, Perl 6 (aka Raku), R, C#, ...). Many languages have extensions for multiple dispatch incl. C, Factor, Java, Python, Scheme, Ruby, ...)...
But I am also pretty sure that whatever replaces Julia in the future, it will have borrowed heavily from Julia in terms of semantics, syntax, libraries etc. Multiple-dispatch that Julia pioneered is almost certainly going to dominate future languages.
This is in similar ways to have functional programming has entered almost every mainstream language and OOP entered almost every language before that.