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.

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.

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.

Maybe, but I think the only app store that does vet apps is the Apple one, so that should be the default expectation.

And I think even they wouldn’t manually look for something like this. They’re mainly concerned about people breaking the commercial rules.

Ever tried to follow a large Ruby codebase like Gitlab? Absolutely nightmare. Not only does it not have type annotations, so you can’t follow code by clicking, but you can’t even follow it by grepping because Rubyists seem to love generated identifiers. Even the syntax of the language makes grepping worse, e.g. the lack of brackets prevents you from grepping for function calls like foo(.

Real moral of the story: STATIC TYPING!

Seriously so many people think it’s a waste of time, and then stuff like this happens.

Microsoft doesn’t have a vetting process for publishing extensions in the store. Maybe the failure is that people assume they do?

You can count Ruby out immediately. Terrible language.

Also replace JavaScript with Typescript. It’s strictly superior.

I don’t think Go has any mature GUI libraries.

For desktop GUI your main options are:

• Qt, via C++. Probably the best option but if you don’t know C++ that’s a huge barrier.
• Qt, via Python. Reasonable but Python is quite a shit language. It’s very slow and the tooling/infrastructure is absolutely abysmal. Be prepared to bang your head against the wall trying to e.g. get relative imports to work.
• Dart/Flutter. This is quite nice but not super mature for desktop apps. Also the Dart ecosystem is very small so libraries you want may not be available.
• Electron/Typescript. This is quite a good option. Nobody here will recommend this because nerds have a slightly weird hatred of Electron because the minimum download size is like 80MB. But normally it doesn’t really matter. Especially for big apps.

For the web frontend you basically want Typescript. For the backend you can use literally any language.

I would recommend Electron for the GUI and Typescript for the web frontend and Electron GUI. It means you can use the same language everywhere and you won’t need to even implement the same program twice.

If you’re worried about the download size / RAM usage you can look into Tauri which uses your OS’s browser engine. I’ve never used it though.

Yeah but be prepared for a lot of pain if you want to distribute your app. Python tooling/infra is abysmal.

Haven’t tried Mojo yet but I have tried Julia and it kinda sucked balls. Sorry Julia fans, but it did. My main complaints:

• It’s a research language like MATLAB, so the emphasis is on repl’s, trying things out etc. But the compilation model is like C++. When you import a package it spends like 2 minutes compiling it. I think it’s supposed to cache it but the second time it was still like 10 seconds for me just to import a package. I believe they’ve improved this since I used it but still, huge red flag.
• 1-based indexing. Come on guys. Anyone using this is smart enough to learn 0-based indexing. It’s like putting a steering wheel in a jet fighter because you worry about pilots getting confused by a joystick. Again, red flag.
• The plotting libraries (a core feature for this sort of language) kind of sucks. In fairness nothing comes close to MATLAB on this front. I ended up paying for MATLAB because of that.

There’s also this article which has more reasons.

I am leaving it a while longer before I try Mojo.

I mean… let’s just hope he isn’t doing this professionally.

Yeah possible, but this of the amount of effort that would take!