Oberflächlich betrachtet ist auch die Anzahl der Codezeilen (LOC) wichtig. Im Hinblick auf die Produktivität macht es einen Unterschied, ob man eine Seite liest und versteht oder drei Zeilen liest und versteht.

Natürlich nutze ich in der Produktion ebenfalls bis zum Überdruss .asyncio, aber mit der aktuellen Nutzungserfahrung bin ich nicht so zufrieden, dass ich sagen würde: „Ich nutze es gut.“

Das heutige asyncio ist gewissermaßen eine Ausweichstrategie für den GIL, da es unter der Voraussetzung des GIL entworfen wurde; insofern interagiert der GIL nicht direkt mit asyncio.

Betrachtet man jedoch die gesamte auf asyncio basierende Concurrency-Programmierung, dann ist die Aussage, der GIL sei irrelevant, meiner Meinung nach so etwas wie: „Weil es Python ist, ist es selbstverständlich, dass es nicht geht.“

Ich stimme zu, dass man kaum erwarten kann, dass die aktuelle Richtung beim GIL im Vergleich zu „anderen Alternativen“ in nichts nachsteht.
Aber wenn man sagt, man müsse statt Python andere Alternativen wählen, sollte das dann nicht eher zu der Argumentation führen, dass es ein Problem gibt, statt zu der Argumentation, dass es kein Problem gibt?

Diesmal habe ich aus rein persönlichem Interesse einmal Webentwicklung ausprobiert, also ein Bereich, der überhaupt nichts mit dem Feld zu tun hat, in dem ich ursprünglich entwickelt habe. Ich habe mit dem Next.js v15 App Router ein Board gebaut ... aber jedes Mal, wenn ich solche Beiträge sehe, verliere ich irgendwie die Motivation, im Web-Bereich etwas Neues auszuprobieren. Warum ist dieses Ökosystem nur so instabil? Und wenn dann wieder etwas Neues erscheint, stürzen sich alle darauf, nutzen es eine Weile und schimpfen dann wieder, während sie nach etwas anderem suchen? Webentwicklung scheint wirklich nicht leicht zu sein.

Macht und Geld sind letztlich die treibenden Kräfte dafür, dass ein Projekt weitergeführt wird.
Und jedes Mal, wenn ich eine Webseite sehe, die ohne Chromium nicht richtig funktioniert, kann ich mir einen Seufzer einfach nicht verkneifen.

Ehrlich gesagt ... außer Google gibt es wohl kein Unternehmen, das Chrome auch nur annähernd auf diesem Niveau halten könnte. Außerdem ist die Dominanz im Webbrowser-Markt zwar nicht ganz mit der bei Halbleitern vergleichbar, aber dennoch ein Bereich, den die USA nur ungern aus der Hand geben würden ... ich denke, dass auch künftig ein gewisses Maß an Monopolstellung toleriert wird.

Ich habe es erst spät gesehen.
Vielen Dank für die ausführliche Antwort!

Fühlt es sich nicht schnell vertraut an, selbst wenn es zunächst unbequem ist, sobald man es eine Weile benutzt?
Der Mensch ist ein anpassungsfähiges Wesen.

Im Text wird das zwar nicht ausdrücklich klar gesagt, aber könnte damit nicht gemeint sein, dass mit KI geschriebener Code zu technischem Schulden führt, weil er einem im Vergleich zu von Menschen direkt geschriebenem Code weniger vertraut ist?

Oh, ich war auch zahlender Nutzer, haha.
Als ich in der App-Store-Historie nachgesehen habe, wurde es ab Version 1.51 kostenlos.
Für mich ist es ein unverzichtbares Tool, weil sich die Monitoreinstellungen meines MacBook je nach Einsatzort unterscheiden.

Man schreibt ja keinen wissenschaftlichen Aufsatz, also ...

Der GIL wirkt hier irgendwie etwas unvermittelt erwähnt … Aber selbst wenn der GIL entfernt würde,
wäre es dann nicht besser, statt Python eine andere Alternative zu wählen,
wenn man sowohl bei I/O-bound- als auch bei CPU-bound-Workloads Multithreading nutzen möchte …

Bei asyncio habe ich auch den Eindruck, dass die Abneigung unter Leuten, die tief in Python drinstecken, ziemlich stark ist.
Ich habe öfter die Meinung gehört, dass eigentlich gevent zum Mainstream hätte werden sollen.

Danke für die Vorstellung dieser tollen App.

Ich habe zusätzlich etwas geschrieben.

asyncio wird viel genutzt … es ist durchaus brauchbar. Es gibt zwar die Einschränkung, dass das Abbrechen von Tasks edge-triggered erfolgt (und nicht level-triggered), aber in der Praxis schreibt man ohnehin eher selten Code, der sich des Task-Abbruchs bewusst ist und ihn graceful behandelt. Das größere Problem ist eher, dass der Event Loop nur eine Weak Reference auf Tasks hält und diese daher durch den GC verschwinden können … das lässt sich aber mit Structured Concurrency lösen.

Für die meisten wichtigen I/O-bezogenen Aufgaben ist es kein Problem, Bibliotheken mit asyncio-Support zu finden …

Mit dem GIL hat das nicht besonders viel zu tun … der Ansatz, asyncio für parallele CPU-intensive Aufgaben einzusetzen, wirkt an sich schon etwas seltsam. Wenn der GIL verbessert wird, dürfte das für CPU-intensive Multithreading-Workloads nützlich sein … Async dient dazu, I/O-Engpässe möglichst effizient auszunutzen …

Wie auch immer, das Fazit … es gibt zwar einige Designprobleme, aber beim Erreichen des Ziels gibt es in der Praxis keine besonderen Schwierigkeiten, und wir setzen es in Production gut ein.

Auch wenn es sich um einen MITM-Angriff handelt: Wie haben sie denn die HTTPS-Kommunikation entschlüsselt? Bin ich der Einzige, der das nicht versteht?

Wie steht es wohl im Vergleich zu Biome um die Geschwindigkeit?

Ich bleibe einfach bei joblib.

Natürlich kann ein wichtigerer Grund sein, dass der Nutzen, den man überhaupt erzielen kann, wegen des GIL im Vergleich zu anderen Umgebungen geringer ist.
Ich halte die Formulierung, ohne GIL könne man Synergien erzielen, für nahezu irreführend. Wenn man einem Läufer, dem ein Bein fehlt, eine zwar unbequeme, aber immerhin funktionale Prothese gibt – ist das dann wirklich eine „Synergie“?