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

**URL:** <https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030>\
**Category:** Community\
**Created:** [August 19, 2022, 5:42pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030 "2022-08-19T17:42:29Z")\
**Posts on this page:** 1\
**Showing post:** 105

<div class="post-metadata">

**Author:** ![gbellomia](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gbellomia/32/19443_2.png) [@gbellomia](https://discourse.julialang.org/u/gbellomia)\
**Post date:** [September 23, 2022, 1:44am UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/105 "2022-09-23T01:44:24Z")

</div>

> [@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)](https://discourse.julialang.org/t/allocation-and-slow-down-when-of-types-involved-increase-slower-than-c-virtual-methods/87656/3):
>
> 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](https://en.wikipedia.org/wiki/Virtual_method_table) 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.

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](https://discourse.julialang.org/t/claim-false-julia-isnt-multiple-dispatch-but-overloading/42370/133) 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](https://discourse.julialang.org/t/allocation-and-slow-down-when-of-types-involved-increase-slower-than-c-virtual-methods/87656/3) 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.

---

_[View the full topic](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030)._