Why not just use the faster language?

Because the other language is more developer-friendly or faster to write/read even if slower to execute. Some code doesn't need to be fast because it is always waiting on other things anyway.

Some languages effectively prevent whole classes of runtime failures / bad code. But, they do that by doing more which takes longer, at compile-time, run time, or both.

Some programs can't avoid graph-structured data dependencies. In that case, the simplest solution is a garbage collector, and one built into the runtime is capable of being more efficient (and less buggy) than one written for a specific program.

Anyway, there are many factors that determine which language is "best", and not all of them are objective. That's why we don't just use the fastest language. (Currently, I do all my coding in either Idris or Purescript, but I'm also unemployed and just programing for myself, for now.)

Then its the Test environment that is slow, not Python.

Lua also doesn't provide everything Python does and has a totally different use case.

To me performance is almost always bad engineering choices like not understanding or handling I/O.

So that means every single developer that has ever used Electron or CEF for something, has been making bad engineering choices?

You may have something there.

Pay me to do it and I'll gladly do it. Most companies, however, don't really care much about whether the customers take an extra 100 milliseconds for every request or not. And when it's promotion time, you're often judged by how many tasks you get done, not how fast your code is.

This seems like a pretty good article, if you like to think. Sure the author is a sceptic but not at all dismissing the usefulness of ai. They are trying to challenge the marketing hype and promote constructive feedback and discussion. Makes sense that this is something companies trying to dump their overvalued stock don't like and may even use bots to burry.

Ah okay, I see what you're saying. GIL removal can break FFI code through the C API.

I have a lot of thoughts on this, and most of it is too incoherent to put into a comment someone else can understand, but for the most part, I think the issues are still pretty overblown. I just can't see a world where Python needs true multithreading support when multiprocessing works just fine for most applications. You find a hot loop, you parallelize it in multiprocessing and just like that, your process runs much faster.

I do think that GIL removal is a terrible idea in general, for the reasons in the quote you provided, but at least it's optional. I would personally not enable it in anything I maintain for several years if I didn't have to.

I also think that polyglot code running in the same process is also a bad idea. I can understand calling C or Fortran from Python for numerical processing for example, but doing the reverse (like calling Python from Rust) is something I try to avoid at all costs. In any project I've worked on, if significant portions of the codebase were written in different languages, you would just use something like protobuf to specify the I/O protocol between the different languages and call them across a socket. It's easier to maintain in my opinion since it defines a concrete boundary between the two different portions of code, and also makes it much easier to test each component separately too.

It's mostly because of memory cache misses. JS creates a ton of closures and has a lot of context switching. JS engines are basically a modern day miracle for how fast they are but somehow webapps are still sluggish.

IMHO it's easier to quickly iterate with Python than with C++. If you aren't even sure what you want and you're just writing stuff, then Python is great. Is "4" true? Ofc it is.

I mean, python has a very nice set of tools that run at C speed so it's not crazy to think you can get good performance out of it.

over half of that 70% is just wordpress.

4

Well nginx brotli is probably most important

"coding" 🫪

Can we get Samuel L. Jackson to read it for those with vision impairment?

Can't, I was thinking of MSN.com but they had a redesign sometime, they come in at 5.6mb now

the person getting the burger actually has a user agent which fetches the burger for them. Its a food delivery app and the browser is doordash/uber eats etc. Instead of packets its human beings who read a screen and understand obligations.

What does that even mean? I make GUIs in web technologies, I make GUIs in godot, I make GUIs in bevy, I make GUIs in flutter, etc etc. Blink uses Skia. Flutter uses Skia. Is skia just bad? What are you even saying? What is slow about web tech, really? To me performance is almost always bad engineering choices like not understanding or handling I/O.

Never understood the idea of, "if it needs to be fast, that part is in a faster language." Why not just use the faster language? Most of the libraries that have Python wrappers also come with c headers. Sometimes you wind up in the reverse situation where your dependency doesn't have a Python wrapper and now you're stuck managing silly boilerplate. Python just feels like an extra thing in the way to wrangle for little gain.

Also, hotspot-only optimization doesn't seem to have held up in reality, right? We can all agree that software is getting slower every day. The infrastructure is slow.

All feels like cope, through and through.

Thanks for putting numbers. People really overblow python performance issues when it literally does not matter most times.

Has everyone forgotten the art of creating or using performance profiling tools

Awww, not brotli. Bummer.

The cook should be represented as the database.

Back in the 80's, my brother "hacked" a pizza place because he knew how they wrote green olives and black olives on their ticket. He dated a girl who worked there for a stint.

I don't remember how it worked and he has since passed, but it was something with the order that he would list the toppings that would fuck up the cook, so the order always came out wrong and boom! Free pizza.

God, this again.

It's not outdated, and maybe you didn't get what I was talking about, but probably because I didn't word it well. So let me quote someone else instead:

While pure Python code should work unchanged, code written in other languages or using the CPython C API may not. The GIL was implicitly protecting a lot of thread-unsafe C, C++, Cython, Fortran, etc. code - and now it no longer does. Which may lead to all sorts of fun outcomes (crashes, intermittent incorrect behavior, etc.)

This covers the layers below python, but still doesn't fully cover the process wide restrictions (it's not just about thread safety, global initialization and resources are very relevant too). It also doesn't cover the exact same problem which also exists for any layer calling into python from above, which also relies/relied on the GIL for synchronization. This means that you can't effectively, confidently, and safely scale python without scaling the number of python runtime instances, each in its own full OS process.

The fact that multiprocessing became popular, instead of just scaling/parallelizing with threads, is itself an extension of the GIL/no-GIL circus. But its not the primary point here.

So not only the proposition (which someone referenced in another sub-thread) to move everything into python is in and of itself a self-defeating argument, since it proves a language being a problem (through forcing language lock-in). But even within a language (python), not all problems are solvable still.

Note that this is not all theoretical for me. In one of my previous projects, I had to call into a python library (which didn't have an adequate alternative) from rust code (through pyo3). And I was forced to scale with multiple python runtimes, each getting one request/message at a time.

And we still didn't get to any low-level details yet 😉