# 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:** 8\
**Page:** 6

<div class="post-metadata">

**Author:** ![Nathan\_Boyer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nathan_boyer/32/14825_2.png) [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)\
**Post date:** [September 1, 2022, 1:53pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/101 "2022-09-01T13:53:25Z")

</div>

I _very_ rarely see **impolite** or **unfriendly** answers on this forum, even when [OP really deserved some](https://discourse.julialang.org/t/pde-heat-diffusion-solution/64027). I personally think we are quite good at that. I do, however, occasionally see **unsympathetic** or **unhelpful** answers, which are IMO the topic of this thread.

---

<div class="post-metadata">

**Author:** ![jacobusmmsmit](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jacobusmmsmit/32/217669_2.png) [@jacobusmmsmit](https://discourse.julialang.org/u/jacobusmmsmit)\
**Post date:** [September 1, 2022, 2:05pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/102 "2022-09-01T14:05:17Z")

</div>

As inappropriate a reaction it may be given the topic of this thread, that link did give a good chuckle :')

---

<div class="post-metadata">

**Author:** ![Eben60](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/eben60/32/13475_2.png) [@Eben60](https://discourse.julialang.org/u/Eben60)\
**Post date:** [September 1, 2022, 3:18pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/103 "2022-09-01T15:18:08Z")

</div>

> [@DNF](#):
>
> Polite questions get polite answers. Other questions **might** get matching replies. Since this is not a professional help desk with paid employees, that is perfectly fine.

> [@Sukera](#):
>
> No, that is _exactly_ what I took from the part I quoted, which says **precisely** that there are polite questions, and _other_ questions (i.e., not polite ones? If not that, what else are “other” questions?) that **should** get a matching reply.

??? (just to avoid being rude)

---

<div class="post-metadata">

**Author:** ![Ribeiro](https://avatars.discourse-cdn.com/v4/letter/r/d9b06d/32.png) [@Ribeiro](https://discourse.julialang.org/u/Ribeiro)\
**Post date:** [September 8, 2022, 7:16am UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/104 "2022-09-08T07:16:18Z")

</div>

In my experience, people here are extremely helpful and nice. _However_, there’s often a product manager approach to answering some types of questions, which I find unhelpful.  
In particular, sometimes people come in with real issues (not “Julia is not exactly how I want it to be”) and people’s answers are more “you shouldn’t be doing that” or “why would you want to do that” instead of “yeah, that is a limitation”.  
I don’t want to point fingers, so I won’t link to any posts. I’ll just say there are numerous topics asking for help in compiling Julia code to a small .exe and lots of answers try to convince the OP that open source is the only way to go and users should be able to modify code, instead of acknowledging this is indeed a limitation and that it’s fine if it’s a deal breaker. Same goes for time to first plot, where people often try to convince others this is not a problem or talk about how much it improved, instead of going straight to acknowledging the limitation and suggesting the well known workarounds (while acknowledging their imperfect nature).  
So it seems to me people are quite defensive.  
But again, very friendly and helpful as a community. I’ve been helped numerous times here.

---

<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.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [September 23, 2022, 12:27pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/106 "2022-09-23T12:27:25Z")

</div>

> [@gbellomia](#):
>
> avoid (let me add here a “true”) runtime semantics and stick to devirtualization

Devirtualized dispatch still uses runtime _semantics_. It still avoids the expression problem (you can add new virtual methods to existing types, and new types to existing virtual methods, and use both in type-generic code).

Exploiting the devirtualization optimization mainly means that you want to avoid highly heterogeneous _containers_ in critical inner loops (besides some fairly superficial coding-style constraints like type stability). This seems to be only rarely a burden in practice.

---

<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, 12:45pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/107 "2022-09-23T12:45:18Z")

</div>

Well, the occasional references to the expression problem are another source of confusion for me about this “dynamic vs static” thing:

 ![IMG_20220923_143940](https://global.discourse-cdn.com/julialang/original/3X/9/b/9b336fd936cd72a37ae5bf5cb15c01f7ba018b51.jpeg)

As formulated on Wikipedia, the expression problem concerns statically typed languages and requires static semantics (yes I know you don’t do casts in Julia… it’s just that your core-language semantics lie somehow outside all of this pre-existent formalizations I guess). You may have found the definitive solution, or you may be a little cavalier about these kind of statements. I don’t really know.

---

<div class="post-metadata">

**Author:** ![cdawg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cdawg/32/9811_2.png) [@cdawg](https://discourse.julialang.org/u/cdawg)\
**Post date:** [September 23, 2022, 12:56pm UTC](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030/108 "2022-09-23T12:56:53Z")

</div>

Well it’s 100 comments in, but I think maybe the biggest problem is simply that we LOVE Julia and love is a strong emotion. We know the flaws as well as anyone. We pay for the pain points in blood, but we believe, we hope and try not to hope too much but it’s just SO GREAT when you get some crucial code down to 0 allocations. When haters hate on your team you can’t always be super rational. I just want to say that coding is something I spend a lot of time doing, and I’d rather feel the love and excitement and be a little irrational with the haters than play it cool and code in C++. Ideally we’d feel the love and keep the cool, and I think we usually do. Extreme value statistics on the distribution of humans comprising a community drive a lot of perceived irregularities.

[Previous page](https://discourse.julialang.org/t/we-as-a-community-should-be-more-understanding-of-julias-flaws/86030.md?page=5)