I totally agree that conflating these is most probably wrong, but I also think the marketing issue has popped up fast in the thread for a good reason: the two aspects are intimately related imho, more than what I feel the general consensus here is.
As an actual outsider of the language (have wrote less than 1000 lines of Julia yet, but gravitating around with fluctuant interest) I actually believe that in some sense you, as a community, should choose which of the two aspects (marketing vs social “aggression”) you want to “be a problem” and let the other be “all good”, since they are kind of complementary. If people are bringing up marketing and expectations here is maybe just because they do not agree on this implicit “choice” about which of the two is the main issue.
Going explicit on “how and why” they are complementary, let’s take one of the forms of the “solved 2-lang problem” slogan: faster than c++, easier than python.
-
if you want this to be a reality (maybe with “as mush as” formula instead of “more than”, ok) then you should totally avoid bashing people for “allocating like crazy” (on a personal note, I also find exactly this kind of mocking tone strongly pushing me back from the community), since keeping attention to this level of details --maybe even worse with type stability-- greatly moves away from the “python-like easy” perception.
-
but you can very well prefer to hold the position that a user that wants performance would inevitably need to dive deep in such critical details, and so you would rather keep your “right” to explain why the user is failing to code idiomatically (or even appropriately in general for the problem at hand) and suggest to investigate more on these fundamental quirks before complaining about supposed flaws of the language. (in a kind way, of course, about tone I see no excuses and I’m quite happy about the consensus here)
From this latter perspective, I think one should seriously consider to drop the vision (if not even a claim that we are already there) of a language that’s at the same time easy, dynamic, remarkably expressive and outstandingly performant.
Let’s be clear I think Julia can be each of these, there is much evidence about best-in-class speed, it’s quite easy to demonstrate a huge degree of dynamism and we all know how much expressive mutiple dispatch can be. But after reading many many discussion here I got that you can’t have the whole cake, every time people has performance issues the advice inevitably lowers to “reduce drastically your dynamism, maybe even freeze it all”.
I actually think it’s very very very nice that Julia allows you to have both styles and to exploit the wild dynamism while fast prototyping, and then optimize the production code by just polishing and giving dynamism up afterwards and where is relevant, without needing to switch language (and so style) all together for everything. In this sense yes, the 2-lang problem is solved, I agree. But I don’t think all these slogans, in any form, really deliver this exact message. People really expect instead to have both dynamism (et. al) and bare-metal performance working together and I just fail to see that happening anywhere near in the future. Like really, a language that is actually extremely dynamic and at the same time blazing fast is a huge promise, and a beautiful (greedy? semicit.) one.
Some time ago there was a very long thread, “Claim (false): Julia isn’t multiple dispatch but overloading” and while I agree with the general community response (Julia is totally able to dispatch at runtime and has no notion of static types, so that’s the semantics in the language) I find the critique had an hidden bit of truth: you can have runtime multiple dispatch and it opens wonders about composability but then you have inevitable performance pitfalls, unless you tame the actual runtime nature. So, apparently, what you all really want as the “unreasonable driver of julia success” (semicit.) is actually static “inferrable” multiple dispatch, very similar to overloading, in many ways. Again all communication about multiple dispatch focuses strongly on its inherent dynamic nature but any performance advice screams at you “no! do not touch the marvelous toy I just praised to you, bad kid”. So people feel betrayed in their expectations, you had promised a golden apple, you are afterwards mocked for believing it too much. Managing expectations would go quite a long way on perception and probably remove many “dumb questions” from your daily discourse walk: something like “we have something more powerful than static overloading since compile time is intermixed with runtime and you can have a fair bit of dynamism on your dispatch but beware, you have to carefully dose how much dynamism you put in to avoid serious performance pitfalls” sounds quite better than “multiple dispatch unleashes powerful dynamic composability within a C-speed language… oh, you have crazy type instability, how you dare complaining about performance, you dumb”, doesn’t it?
Sorry for the very long comment, I initially intended to be way more concise. I would like to give it an end by noting that from comments like
I understand that some of you may be aligned with the latter “worldview” (as I am, in general, for whatever performance-oriented language) but this to me is in fair conflict with statements like
if the aggressive marketing keeps relying on the “both easy and performant” adage. (sorry @jacobusmmsmit, did not really want to take both quotes from you, they are just an example of the friction I see here). The claims are well substantiated as far as performance goes, but not really if you expect that much easy of usage in the same code.