I don't like NumPy

One of the reasons why I started using Julia was because the NumPy syntax was so difficult. Going from MATLAB to NumPy I felt like I suddenly became a mediocre programmer, spending less time on math and more time on "performance engineering" of just trying to figure out how to use NumPy right. Then when I went to Julia it made sense to vectorize when it felt good and write a loop when it felt good. Because both are fast, focus on what makes the code easiest to read an understand. This blog post encapsulates exactly that experience and feeling.

Also treating things like `np.linalg.solve` as a black box that is the fastest thing in the world and you could never any better so please mangle code to call it correctly... that's just wrong. There's many reasons to build problem specific linear algebra kernels, and that's something that is inaccessible without going deeper. But that's a different story.

"Then when I went to Julia it made sense to vectorize when it felt good and write a loop when it felt good. Because both are fast, focus on what makes the code easiest to read an understand."

This is true of modern Fortran also.

The amount of work that's been put into Fortran by the LFortran [1] folks and others in recent years [2] is nothing short of absurdly impressive!

[1] https://lfortran.org/

[2] "in recent years" because that's when I became aware of this stuff, not to say there wasn't effort before then

Indeed, I also like modern Fortran.

If you’re going to give praise, include the GNU Fortran developers, who have really set the standard for open source production quality Fortran compiler development.

> Going from MATLAB to NumPy I felt like I suddenly became a mediocre programmer, spending less time on math and more time on "performance engineering" of just trying to figure out how to use NumPy right.

Matlab is about as slow without readily vectorized operations as Python.

Slowness of Python is a huge pain point, and Julia has a clear advantage here. Sadly Julia is practically just unusable beyond quite niche purposes.

Python does now have quite serviceable jit hacks that let one escape vectorization tricks, but they are still hacks and performant Python alternative would be very welcome. Sadly there aren't any.

One of the things i suspect will happen very soon is that all languages will become as fast as each other and your reason to use one over the other for performance reasons might not exist. I know this sounds optimistic and wishful thinking but hear me out here;

Modern AIs are literal translation engines. That's their origin. The context that lets them do what they do was originally there to allow good translations. It doesn't matter if the translation is programming language output, or actual language output. I can today ask an AI to rewrite a chunk of Matlab code into Rust and it works! There's even code generators that will utilize the GPU where sensible.

We're really not that far off that we can write code in any language and transparently behind the scenes have it actually running on a more performant backend when needed. Ideally you keep the Matlab/Python frontend and the translation will be on the intermediate layers in a two way fashion so step through/debug works as expected.

Based on playing with the above steps manually with good results we're almost at the stage of just needing some glue to make it all work. Write in Matlab/Python, and run as fast as any LLVM backed language.

> Sadly Julia is practically just unusable beyond quite niche purposes.

Why? Just the ecosystem?

The reason is quite simple. Julia is a language designed for scientific computation. Numpy is a library frankenstein-grafted onto a language that isn't really designed for scientific computation.

We can only hope that Julia somehow wins and those of forced to work in python because of network effects can be freed.

Sounds like transpiling Typescript to JavaScript, except that you translate to a vastly different language, thereby making you, the programmer, largely unable to reason about the performance characteristics of your code ("Can the transpiler optimize this Python loop or nah?"), and you also throw in the indeterminism of LLMs. Oooof, I'm not sure I'd want that.

Mainly the lack of practical support for non-REPL/Notebook usage and interoperability.

Is MATLAB materially different? Loops are slow (how slow depends on the version), and the fastest thing in the world is the utter perfection of the black box called '\'.

When you're using Python the type of performance characteristics you're usually thinking of are "can i call an external library that runs this on the GPU" or "is this log(n) or n^2 complexity?" and such language translations shouldn't change those parts.

As in the language is regularly benchmarked at 10-100x slower than other languages. It's not a languages for caring about subtle performance characteristics outside "am i calling the external library correctly or not?" (as in this article) or "is this algorithm exponential time?".

R

R is for sure not a Python replacement. And it's even slower than Python.

That sounds great, kudos to them too!

The only times I set foot in the Fortran world is when some Julia-related development [1] [2] happens, and then I peruse some surrounding links and related projects - so I have very little familiarity with GNU Fortran myself.

[1] https://fortran-lang.discourse.group/t/update-on-prima-a-jul... [2] https://discourse.julialang.org/t/ann-julia-back-end-for-lfo...

The last time I seriously used Matlab, over 10 years ago, they had implemented JIT compilation and often straightforward loops were a lot faster than trying to vectorize. And definitely less error-prone.

Iirc, ‘\’ was just shorthand for solving a system of equations, which you could mentally translate into the appropriate LAPACK function without loss of precision. You did have to be a little more careful about making extra copies than in Fortran or C (or even Python). But nothing was magic.

I've found matlabs's JIT to be about on par with numba for loops.

I've been hoping this for 15 years, but so far I still use Python for everything.

This has me wondering, if not that, then what is python designed for?

Nah, because "Python is second-best at everything" and has more libraries than the Galactic Federation, that will never happen.

R has significant performance advantages over Python if you are keeping it in its lane. But it's a DSL and not a general-purpose language.

Julia really needs to generalize and clarify its deployment story before it could possibly take off. It was built with a promise of generality but its tethered packaging is an albatross.

I like drag racing too, and modern Fortran is really competitive on the track. But I think I need a car that is street legal for my needs.

“quite niche purposes”

I don’t understand this. Julia is a general-purpose language that I increasingly use to replace bash scripts. I’ve also happily used it for web scraping tasks¹, interactive web² projects³, generation of illustrations and animations, and, yes, scientific calculations. Aside from the language itself, which is fun to program in, its brilliant package system massively facilitates composing libraries into a solution.

1 https://lee-phillips.org/amazonJuliaBookRanks

2 https://www.admin-magazine.com/Archive/2025/85

3 https://lee-phillips.org/pluckit

To be general purpose with a very large package ecosystem so that you can get just about anything started pretty quickly. It is relatively easy to do things that aren't performance critical with python, which is great if you want an MVP to grow off of or if you're messing around with something and want to make a little flask server for it, or maybe run some image recognition, or a little anything. It's really just insanely flexible and puts a lot of the cognitive load in libraries so you can get straight to doing stuff, again, often at the cost of performance.

The best description I heard of Python is "glue for C libs".

There are enough ambiguities between language libs, even different versions of the same lib, that transpilation will always depend on verification.

It'll work for toy examples. For nontrivial code the generated transpilation will flame out in a different way on every run.

Interop with what? It has a very good FFI for C, PyCall, RCall, etc. work quite well.

It is pretty REPL focused, but what is the thing you want that you don't have? Like better debugger support in VSCode or something?

Just happened to find this article, seems to do a good job of explaining why.

https://news.ycombinator.com/item?id=44013455

Originally a scripting language - from what I recall. An alternative to Perl or Tcl.