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

I very rarely see impolite or unfriendly answers on this forum, even when OP really deserved some. 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.


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


??? (just to avoid being rude)

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.


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:

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.

    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.

1 Like

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.

1 Like

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

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.

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.