Saving this for the next “Year of desktop Linux” discussion 😄

Glad you recovered it.

IMO Julia just had way too many big issues to gain critical mass:

1. Copied 1-based indexing from MATLAB. Why? We’ve known that’s the worse option for decades.

2. For ages it had extremely slow startup times. I think because it compiles everything from C, but even cached it would take like 20s to load the plotting library. You can start MATLAB several times in that time. I believe they improved this fairly recently but they clearly got the runtime/compile time balance completely wrong for a research language.

3. There’s an article somewhere from someone who was really on board with Julia about all the issues that made them leave.

I still feel like there’s space for a MATLAB replacement… Hopefully someone will give it a better attempt at some point.

Anything that helps scientists and engineers move away from MATLAB is welcome.

The MATLAB language may be pretty bad but IMO that’s not what makes MATLAB good. Rather it’s:

1. Every signal processing / maths function is available and well documented. I don’t know how well Julia does on this but I know I wouldn’t want to use Python for the kinds of things I used MATLAB for (medical imaging). You don’t have to faff with pip to get a hilbert transform or whatever…

2. The plotting functionality is top notch. You can easily plot millions of points and it’s fast and responsive. Loads of plotting options. I just haven’t found anything that comes close. Every other option I’ve tried (a lot) only works for small datasets.

I am indeed thinking of CPython because a) approximately nobody uses PyPy, and b) this article is about CPython!!

In any case, PyPy is only about 4x faster than CPython on average (according to their own benchmarks) so it’s only going to be able to compete with C++ in random specifics circumstances, not in general.

And PyPy still has a GIL! Come on dude, think!

Yeah exactly. You made it faster through algorithmic improvement. Like for like Python is far far slower than C++ and it’s impossible to write Python that is as fast as C++.

Sure but that’s not relevant to the current discussion. The point is that removing the GIL doesn’t affect Numpy because Numpy is written in C.

Pip and venv have been tools that I’ve found to greatly accelerate dev setup and application deployment.

I’m not saying pip and venv are worse than not using them. They’re obviously mandatory for Python development. I mean that compared to other languages they provide a pretty awful experience and you’ll constantly be fighting them. Here’s some examples:

• Pip is super slow. I recently discovered uv which is written in Rust and consequently is about 10x faster (57s to 7s in my case).
• Pip gives terrible error messages. For example it assumes all version resolution failures are due to requirements conflicts, when actually it can be due to Python version requirements too so you get insane messages like “Requirement foo >= 2.0 conflicts with requirement foo == 2.0”. Yeah really.
• You can’t install multiple versions of the same dependency, so you end up in dependency resolution hell (depA depends on foo >= 3 but depB depends on foo <= 2).
• No namespace support for package names so you can’t securely use private PyPI repositories.
• To make static typing work properly with Pyright and venv and everything you need some insane command like pip install --conf-settings editable-mode=compat --editable ./mypackage. How user friendly. Apparently when they changed how editable packages were installed they were warned that it would break all static tooling but did it anyway. Good job guys.
• When you install an editable package in a venv it dumps a load of stuff in the package directory, which means you can’t do it twice to two different venvs.
• The fact that you have to use venvs in the first place is a pain. Don’t need that with Deno.

There’s so much more but this is just what I can remember off the top of my head. If you haven’t run into these things just be glad your Python usage is simple enough that you’ve been lucky!

I’m actually in the process of making such a push where I’m at, for the first time in my career

Good luck!

Python is written in C too, what’s your point?

The point is that eliminating the GIL mainly benefits pure Python code. Numpy is already multithreaded.

I think you may have forgotten what we’re talking about.

the new python version was less than 50 lines and was developed in an afternoon, the c++ version was closing in on 1000 lines over 6 files.

That’s a bit suss too tbh. Did the C++ version use an existing library like Eigen too or did they implement everything from scratch?

The only interpreted language that can compete with compiled for execution speed is Java

“Interpreted” isn’t especially well defined but it would take a pretty wildly out-there definition to call Java interpreted! Java is JIT compiled or even AoT compiled recently.

it can be blazingly fast

It definitely can’t.

It would still be blown out of the water by similarly optimized compiled code

Well, yes. So not blazingly fast then.

I mean it can be blazingly fast compared to computers from the 90s, or like humans… But “blazingly fast” generally means in the context of what is possible.

Port component to compiled language

My extensive experience is that this step rarely happens because by the time it makes sense to do this you have 100k lines of Python and performance is juuuust about tolerable and we can’t wait 3 months for you to rewrite it we need those new features now now now!

My experience has also shown that writing Python is rarely a faster way to develop even prototypes, especially when you consider all the time you’ll waste on pip and setuptools and venv…

numpy

Numpy is written in C.

Numba

Numba is interesting… But a) it can already do multithreading so this change makes little difference, and b) it’s still not going to be as fast as C++ (obviously we don’t count the GPU backend).

Unless the C++ code was doing something wrong there’s literally no way you can write pure Python that’s 10x faster than it. Something else is going on there. Maybe the c++ code was accidentally O(N^2) or something.

In general Python will be 10-200 times slower than C++. 50x slower is typical.

threading bugs are sometimes hard to catch

Putting it mildly! Threading bugs are probably the worst class of bugs to debug

Definitely debatable if this is worth the risk of impossible bugs. Python is very slow, and multi threading isn’t going to change that. 4x extremely slow is still extremely slow. If you care remotely about performance you need to use a different language anyway.

I have yet to see one of these that gives any benefit over ncdu, which is amazing. I guess if you need to log the output this makes sense but that’s pretty niche.

Haven’t tried Rye but I have used uv (which Rye uses to replace pip). Pip install time went down from 58s to 7s. Yes really. Python is fucking slow!

Neat, but I’d really like it to just handle memory properly without me having to tweak swap and OOM settings at all. Windows and Mac can do it. Why can’t Linux? I have 32GB of RAM and some more zswap and it still regularly runs out of RAM and hard resets. Meanwhile my 16GB Windows machine from 2012 literally never has problems.

I wonder why there’s such a big difference. I guess Windows doesn’t have over-commit which probably helps apps like browsers know when to kick tabs out of memory (the biggest offender on Linux for me is having lots of tabs open in Firefox), and Windows doesn’t ignore the existence of GUIs like Linux does so maybe it makes better decisions about which processes to move to swap… but it feels like there must be something more?

We use it for triaging test failure (running tens of thousands of tests for CPU design verification).

That use is acceptable because it is purely informational. In general you should avoid regexes at all costs. They’re difficult to read, and easy to get wrong. Generally they are a very big red flag.

Unfortunately they tend to get used where they shouldn’t due to lazy developers not parsing things properly.

Someone find the commit where they accidentally removed this critical component 😄

Yeah… It’s going to take a whole lot more than $1m for this. I am skeptical.

Also not super enthused about another browser written in C++. I skimmed some of their code and it seems pretty high quality, but still… this is going to be chock full of security bugs.

Servo is definitely the more interesting project.

In normal English, when not using a number, sure! But in software, with numbers versions it almost universally means chronological releases of something.

There are many different versions of Windows, like Home or Enterprise. You can get hardcover or paperback versions of many books.

Great examples! Those are both called “editions”, not versions. Thanks for proving my point 😄

They chose “version” because they are just that, versions. Improvements over the original design that benefit from new insights and technological improvements. We’re lucky they had the foresight to include a version number in the spec.

No they aren’t. A higher version of UUID isn’t “newer and better”, like the word “version” implies. It’s just different. It’s like they called a car “vehicle version 1” and a motorbike “vehicle version 2”. The common use of “version” in the software world would mean that a motorbike is a newer and hopefully improved version of a car, which is not the case.

The talking pumpkin is 100% right that they should have used “type” or “mode” or “scheme” or something instead.