We as a community should be more understanding of Julia's flaws

[gbellomia]

@lmiq

There is hardly any need to reduce dynamism because of the power of generics.

@DNF

I was wondering what you meant by dynamism, I don’t think the above is what first comes to mind for many. When I hear ‘dynamism’ I think expressiveness mixed with genericity/polymorphism. And these you can have, mostly with little or even no negative impact on performance.

@gbellomia

which is what a good part of the Julia hype is about imo.

I don’t think so, or, at least I must have missed that.

@DNF

While multiple dispatch and static overloading are different, I cannot say how important that difference is for everyday work.

I realize that I could not really answer to these kind of comments at the time, but now a comment seen elsewhere helps me a lot:

Allocation and slow down when # of types involved increase (slower than C++ virtual methods)

Dynamic dispatch is slow in Julia — slower than C++ virtual methods, because C++ method dispatch only depends on a single object type (this) and hence can use vtable lookup. High-performance code in Julia always relies on devirtualizing critical code. This also means that you can’t easily write performant geometry code in Julia by having an array of geometric objects of different types and relying on dynamic dispatch to execute different methods (determined at runtime) for different objects —…

This is a (probably much more technically sound…) rewording of the issue behind the “marketing paradox” I was trying to communicate:

1. There are many discussions where both static overloading and single dispatch are completely dismissed as valid alternatives to multiple dispatch, see e.g.

   • https://www.youtube.com/watch?v=kc9HwsxE1OY, where both alternatives are strongly stated as inferior.

   • Claim (false): Julia isn't multiple dispatch but overloading, where you find a veeeery long technical debate about how much —no matter what practically happens in the JIT process— Julia’s multiple dispatch cannot be regarded as equivalent to static overloading (to be clear I agree, semantics-wise, but sometimes one has to be practical…).

   It is even suggested, in both sources, that C++ templating is just syntactic sugar to static overloading, hence less powerful than multiple dispatch. Well, here I want to explicitly answer to @DNF: this is why I think my definition of dynamism matches more to what the community has strongly pushed as the branding of Julia… the whole point made “against” templates is that they have the same semantics of static overloading, hence not capable of dynamism. But in my understanding templates/generics are a first class technology for generic programming and polymorphism, the only thing lacking being runtime behavior, which is why I got that dynamism itself is “a good part of what the Julia hype is about”. Otherwise multiple dispatch would just be (and be marketed as) a respectable alternative to other languages’ solution for generic programming (which is what I think it really is, at this point).

2. As I said many times, but Steven is able to convey way better, whenever performance is relevant you should totally avoid (let me add here a “true”) runtime semantics and stick to devirtualization. As Steven as clarified to me elsewhere this does not really “downgrade” multiple dispatch to static overloading, but still rules out what I was calling “uninferrable dynamism”.

3. In the original post Steven was replying to, you have a real-world example of why there may be a “need to reduce dynamism”, for performance reasons. I still do not really get the technical difference between devirtualization and “call site inference” so I cannot really comment on the power of the mechanism you apparently usually rely into. Maybe that’s the true point generating my concern.