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

[Nathan_Boyer]

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.

[jacobusmmsmit]

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

[Eben60]

@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)

[Ribeiro]

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.

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

[stevengj]

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

[gbellomia]

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.

[cdawg]

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.