Unter Windows kann es auch über scoop installiert werden.

 
woo880 2025-09-04 | übergeordneter Kommentar | in: Ich bin ein AI-Hasser (anthonymoser.github.io)

Ich stimme voll und ganz zu, aber statt der Bezeichnung AI-„Hasser“ wäre vielleicht AI-„Verweigerer“ passender. Die im Wort „Hass“ enthaltene Bedeutung und Konnotation sind nicht gut, und Hass erzeugt schließlich immer wieder Hass.

 

biome ist weiterhin schneller. Aber wenn man nur auf die Geschwindigkeit schaut, ist voidzeros oxlint noch schneller.

Da biome in Sachen Bedienbarkeit und Dokumentation angenehmer ist, wirkt diese Multithreading-Optimierung zwar erstaunlich, aber wenn das bestehende ESLint nicht schneller und zugleich stabiler wird, indem es statt der Kombination ESLint + Prettier auf ESLint + ESLint Stylistic setzt, könnte es am Ende irgendwann doch ersetzt werden.

 

Das sind auch gute Nachrichten für Firefox.
Ohne die Google-Unterstützungsgelder, die nur dazu dienen, zumindest dem Anschein nach keine Exklusivität zu zeigen, würde Mozilla wohl sofort untergehen.
Wenn Chrome wegfällt, gäbe es keinen Grund mehr, dieses Geld zu zahlen.

 

Offenbar hat man noch nicht darüber nachgedacht, dass React die Produktivität beeinträchtigt.

 

Auch wenn Code sehr lang ist, ist er keine Schuld, wenn sich leicht erklären lässt, „was er tut“.

Es geht also darum, dass der unüberlegte Einsatz von AI genau das erschwert und dadurch Schuld erzeugt.

 

Es wurde nicht die Kommunikation gehackt, sondern das Gateway.
Die Spielserver werden je nach Auslastung hoch- und herunterskaliert,
daher teilt das Gateway beim Login mit, mit welchem Server man sich verbinden soll.
Heutzutage kann man kostenlos TLS-Zertifikate bekommen, also lässt sich auch HTTPS sicher aufsetzen, oder?

Gemeint ist wohl, dass das kompromittierte Gateway auf einen falschen Server verweist und dieser Server sämtliche Daten abfängt, wodurch ein MITM-Angriff durchgeführt wird.

 

Das, was in dem Hacker-News-Kommentar darunter steht, trifft es genau.

„Next.js hat in 99,9999 % der Projekte eine riesige Abstraktionsschicht, die man nicht braucht; und in den wenigen Fällen, in denen man so etwas wirklich braucht, ist es meiner Meinung nach besser, stattdessen mit Low-Level-Bausteinen eine maßgeschneiderte Lösung zu bauen.“

Eine unnötig überkomplexe API, instabil und unvollständig, aber trotzdem dreist als production ready beworben, und wegen der enormen Abhängigkeit von Vercel ist ein ernsthafter Betrieb außerhalb von Vercel kaum möglich.

 

Vielleicht liegt es daran, dass ich meine Karriere im Web begonnen habe, aber im Web entwickelt man ursprünglich genau mit diesem gewissen Flair(?) (vor allem im Frontend) haha
So ein rasanter, ständig wechselnder Stil ...

 

Bei JS ist das irgendwie oft so. Es gibt einen ganzen Haufen Dinge, die angeblich gut sind, aber jedes davon hat ein bisschen seine Probleme und ändert sich dem Trend folgend ständig schnell ...
Vielleicht empfinde ich das auch so, weil ich früher vor allem mit Java, EJB und Struts gearbeitet habe.

 

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?