[adgjlsfhk1]

I think the problem here is that there are two very different meanings of "vectorized" at play. The first (and what the Julia docs are talking about here) is the pattern of writing "vector-operations" (i.e. rather than writing a loop, writing an expression that works across an entire array). The second meaning is using SIMD instructions (e.g. AVX2). What the julia docs are trying to say is unlike in languages like Python/R/Matlab where loops have a high overhead do to an interpreter, in Julia, loops are fast because the language is compiled. There are lots of algorithms that are easy to express in an iterative fashion that are pretty much impossible to vectorize efficiently (dataflow analyais/differential equations etc).

The docs here aren't trying to talk about SIMD instructions at all here. (although Julia/LLVM are pretty good at producing SIMD instructions from loops where possible).

[th0ma5]

But no one in science uses Python loops for example, they use NumPy / Jax / Polars etc so that is an unfair and disingenuous comparison.

[adgjlsfhk1]

That's exactly the point. People are changing their coding style to work around the fact that loops in the language are slow.

[th0ma5]

This existed quite a while before Julia, how is it that Julia claims this differentiation then? "We pride ourselves by not using the slow thing you're probably not actually using."

[eesmith]

Because Julia claims to get usability and performance in one language, rather than the two Python needs (Python for the user-facing API, C/C++/Fortran/etc. for performance).

This should also help with optimization, and a larger amount of code can be optimized together, while (C)Python can only optimize up to the Python/C boundary.

[th0ma5]

I can't imagine anything worse than something that is not appropriate for the abstraction... eg https://en.m.wikipedia.org/wiki/Leaky_abstraction

Again redefining these things here... if the language has tools for all of inline raw chip specific instructions, compiler optimized versions of those instructions, virtualized and then optimized instructions, a jit compiler, and then also high level interpreter operations, then how can it be in anyway an encompassing system and how can that be coherent among all levels without requiring someone to know all levels at which point, I'm going to say no thanks and stick to tools at their respective levels of abstraction where I can reason them to be coherent rather than a dynamically allocated string which is sometimes tied to only working on amd64 because someone wanted an assembler way of pattern matching for some reason.

Maybe within the scope of scientific computing this seems logical if you just restrict yourself to matrix multiplication or whatever, but I don't see how that makes a "language" and it can be coherent, composable, etc...

I've seen a ton of examples, however, over the years of "stunt driven" technological advantages that people thought would be interesting but turned out to be the wrong solution for the wrong problem, but none that claim to break the laws of physics and reason with their evangelism than Julia. Even this article starts with "you must understand the quirks" and I hope that isn't a goal for their design because they are also claiming that I shouldn't have to know the quirks so which is it.

[eesmith]

> Leaky_abstraction

Ummm, CPython is also leaky abstraction. Parts of the C implementation, like garbage collection, id(), 'a is b' checks, the ast and dis modules, and more.

It even has the beginnings of JIT support.

The leaky abstraction thesis is that all layers leak.

Julia's argument is that if you have all of these levels anyway, do it in one language instead of two. If you don't like leaky abstractions, you should prefer a system with one less layer of abstraction.

You also reject Rust, yes? It has many of the same abilities.

And JITed Lisp implementations with user access to the JITted code?

> then how can it be in anyway an encompassing system and how can that be coherent among all levels without requiring someone to know all levels at which point

That sounds like an argument from incredulity.

Just because you don't see how something can be true, that doesn't mean it isn't true.

> which is sometimes tied to only working on amd64 because someone wanted an assembler way of pattern matching for some reason

I believe all of the big C compiler vendors support ways to embed assembly. I use it in my code, for better support for x86-64, and a fallback for other platforms.

I also used Turbo Pascal's inline assembly in the early 1990s.

> but none that claim to break the laws of physics and reason with their evangelism than Julia

I guess you're too young to remember Lisp evangelists.

You seem to be reacting to something beyond what is in the linked-to essay. What breaks the laws of physics? Again, appealing to gut instinct isn't that good of an argument.