If I remember correctly, this came up originally in the context of comparing heavily optimized Julia code to C code that had inline assembly, in which a statement was made that Julia was obviously slower than C because the C code had hand written assembly in it. Julia, like C, sometimes needs hand-coded assembly to achieve maximal speed. 80% of a fast programming language is not having semantics that are fundamentally opposed to speed (i.e. object oriented architectures that require pointer chasing, using arbitrary precision numbers everywhere, or eval semantics that prevent interpreting rather than compiling code). Languages that don't make those kinds of mistakes are "not slow". i.e. if you write similar code in them, you will end up with similar performance to C.
Yeah I guess that illustrates how everyone is talking about different things, I just think Julia shouldn't use that to claim they are not as slow as many other things, or other vague promises of high level abilities that can somehow traverse paradigms to become the right thing to do at the low level. The fact that you've similarly called out specific caveats to the argument further illustrates how... In my opinion... It is just simply intellectually dishonest how the Julia documentation categorizes others and how promoters of the language don't really know what it means to say that Julia is fast, it clearly can be made not to be.
You realize that the specific things I called out are things julia doesn't do right? Those are the things in Java and Python and most other high level languages that prevent them from being fast. Julia's semantics specifically don't do those things.
Honestly I don't know why you're replying, it is not really addressing what I'm talking about and using a lot of the argument styles I'm complaining about.
