Der Gründer von Zig sagt die Wahrheit, aber Anthropic prahlt.

 (raymyers.org)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Während Anthropic das Ende des Software Engineerings als Zukunftsversprechen verkauft, wird auch Buns Wechsel von Zig zu Rust kritisiert, weil er für die PR-Erzählung genutzt wurde, dass AI Engineering ersetzen könne
  • Bun nannte Speicherfehler als Grund für den Wechsel, lieferte aber kaum einen Vergleich von Alternativen und Vor- bzw. Nachteilen und legte auch Kosten wie die langsame Kompilierung von Rust nicht offen, weshalb es wie eine nachträgliche Rechtfertigung wirken kann
  • Es hätte auch andere Möglichkeiten gegeben, Zig anders zu nutzen; TigerBeetles TigerStyle zeigt mit statischer Speicherallokation und Simulationstests ein Beispiel dafür, wie sich use-after-free verhindern lässt
  • Der dateiweise Port mit unsafe Rust war ein vernünftiger Ansatz, um Risiken zu senken und spätere Neuentwürfe zu ermöglichen, doch Millionen Zeilen AI-konvertierten Code zu akzeptieren und zugleich ein paar von Menschen lesbare Zeilen zur Pointer-Verwaltung zu problematisieren, wirkt inkonsequent
  • Agent-Harnesses, Rusts borrow checker, Lesbarkeitsregeln und menschliche Reviews bleiben weiterhin nötig, daher sind die Einführung von Coding-Agenten und die Abschaffung des Software Engineerings nicht dieselbe Entscheidung

Das von Anthropic propagierte Ende des Software Engineerings

  • Anthropic treibt aktiv die Erzählung voran, dass nach dem Coding auch das Software Engineering und schließlich der Großteil menschlicher Arbeit verschwinden werde
  • Das Unternehmen hat 132 Milliarden US-Dollar an Investitionen eingesammelt und steuert auf einen IPO mit einer Bewertung von über 1 Billion US-Dollar zu, muss aber in einer Lage, in der es keine Profitabilität nachweisen kann, hypothetischen künftigen Einfluss verkaufen
  • Wegen dieser Interessenkonflikte sollte Anthropic als unreliable narrator betrachtet werden; wichtig ist nicht nur der Wahrheitsgehalt der Botschaft, sondern auch ihr Einfluss auf die Urteile von Führungskräften, Weltpolitikern und Verwaltern von Pensionsfonds
  • Die AI-Erzählung beeinflusst Entscheidungen zu Architektur, Produkten und Personalaufstellung und erschwert nüchterne Urteile in einem Klima aus Entlassungsangst, Warnungen vor dem Abgehängtwerden und Doom Trolling
  • Wer AI im Softwarebereich bewertet, braucht eine skeptische Prüfung, die Anthropics Eigeninteressen und PR-Ziele mit einbezieht

Buns Zig→Rust-Wechsel und die verspätete Erklärung

  • Anthropic/Bun erklärte die Entscheidung, Bun von Zig nach Rust zu portieren, erst zwei Monate nach dem Merge in den Main-Branch in einem Beitrag
    • Bei großen Infrastrukturprojekten ist es üblicher, die Richtung im Vorfeld zu erklären
    • In der Zeit bis zur Erklärung verbreiteten Überschriften wie Anthropic’s Bun Rust rewrite merged at speed of AI den Eindruck, AI habe das Rewrite schnell abgeschlossen
  • Zig-Gründer Andrew Kelley veröffentlichte eine Erwiderung und kritisierte in ungewöhnlich direktem Ton Technik und Organisationsführung bei Bun
    • Reputationsseitig birgt das die Last, einen Präzedenzfall zu schaffen, bei dem der Kopf einer früheren Sprache wegen eines Sprachwechsels sogar persönliche Mängel angreift
    • Manche nannten das einen „meltdown“, aber man kann es auch so sehen, dass hier Probleme öffentlich benannt wurden, die öffentlich benannt werden mussten

Maßstäbe zur Bewertung direkter Kritik

  • Buddhist right speech geht davon aus, dass jede Äußerung die folgenden fünf Kriterien erfüllen sollte
    • Ist sie wahr?
    • Ist sie hilfreich?
    • Ist sie zum richtigen Zeitpunkt?
    • Ist sie freundlich?
    • Geht sie von Freundlichkeit aus?
  • Andrew Kelleys Reaktion fällt unter wahre, aber unfreundliche Rede; strittig ist daher, ob es trotz Verstoßes gegen übliche Höflichkeitsnormen nötig war, die Probleme öffentlich anzusprechen

Das Verhältnis von Bun, Zig und Richtlinien für AI-Beiträge

  • Bun ist eine TypeScript-Runtime, die oft mit einem schnelleren NodeJS verglichen wird, und Zig ist eine Systemprogrammiersprache, die häufig mit einem modernen C verglichen wird
  • Bun war bis vor Kurzem in Zig geschrieben und eine der größten Zig-Codebasen überhaupt
  • Die Richtlinien der beiden Projekte zu AI-Beiträgen sind vollkommen gegensätzlich
  • Nachdem Anthropic Bun übernommen hatte, führte Gründer Jarred Sumner ein groß angelegtes Agentenexperiment durch, bei dem Zig-Code in unsafe Rust portiert wurde; das Ergebnis wurde wenige Tage später gemergt und Teil einer offiziellen Version
  • Unter den Beteiligten scheint niemand dafür einzutreten, Bun weiterhin in Zig zu belassen; die Debatte konzentriert sich weniger auf den Wechsel selbst als auf dessen Begründung und Vermarktung
  • Ein groß angelegter Sprachwechsel mithilfe von Agenten ist ein technisches Experiment, das unter passenden Umständen erneut einen Versuch wert wäre

Drei Deutungen derselben Entscheidung

  • Für Entwickler, die zwischen Zig und Rust wählen wollen, ist es ein wichtiger Anhaltspunkt, wenn einer der größten Zig-Anwender seine Entscheidung zurücknimmt
  • Die Deutung von Anthropic/Bun lautet, dass alle vernünftigen Methoden versucht wurden, Speicherfehler mit Zig aber schwer beherrschbar waren
  • Nach Andrew Kelley wurde die Codebasis durch Engineering-Entscheidungen bei Bun ruiniert, etwa weil AI-Agenten zu viel Schreiben und Review von Code übernommen hätten
  • Eine banalere Möglichkeit ist, dass es für die realen Speicherprobleme mehrere Lösungen gab, das Management sich aber leicht für ein Rust-Rewrite entscheiden konnte
    • Die Fähigkeiten des neuen Fable-Modells konnten beworben werden
    • Anthropic nutzte ohnehin bereits Rust
    • Das Zig-Projekt spricht sich öffentlich gegen die Nutzung von Anthropic-Produkten aus
  • Der Wechsel zu Rust kann geschäftlich sinnvoll sein, doch die Vermarktung fokussiert sich darauf, dass AI stark genug sei, ein Rewrite auszuführen
    • Dass AI use-after-free nicht vorab erkannt hat, kollidiert mit dieser Erzählung
  • Die Übertreibung über Anthropics Lautsprecher stellt die Urteile von Jarred Sumner und Andrew Kelley direkt nebeneinander und kann unbeabsichtigt auch Zigs Ruf beeinflussen

Warum persönliche Glaubwürdigkeit Teil der technischen Debatte wurde

  • Zunächst zur Verantwortung zu ziehen ist weniger der Bun-Gründer als Anthropic, das den Vorfall für seine AI-Erzählung nutzt
  • Weil Anthropic Jarred Sumners Glaubwürdigkeit zur Verstärkung der eigenen Botschaft nutzt, kommt man bei einer Reaktion kaum darum herum, auch seine Urteile und Handlungen zu bewerten
  • Es wäre besser, nur über technische Fragen zu sprechen, aber wenn Anthropics Botschaft stärker auf Show und PR setzt als auf technischen Vergleich, gerät auch persönliche Glaubwürdigkeit in die Debatte
  • Wenn schon das bloße Zusammenstellen öffentlich getätigter Aussagen und Handlungen wie Verleumdung wirkt, könnte dieses Verhalten selbst Teil des Problems sein

Dauer-Crunch und das organisatorische Umfeld bei Bun

  • In einer Stellenausschreibung von Bun aus dem Jahr 2022 wurde gewarnt, dass die ersten neun Monate sehr hart würden und der Job nichts für Menschen sei, die eine Work-Life-Balance mit viel arbeitsfreier Zeit bevorzugen
  • Ein dauerhafter Crunch-Modus schadet sowohl Gesundheit als auch Produktivität; das wird auch in empirischer Forschung zu Wissensarbeit immer wieder bestätigt
  • Man sollte eher einen Manager wählen, der dafür sorgt, dass Teammitglieder nachts schlafen können, als einen, der mit 90-Stunden-Wochen prahlt
  • Andrew Kelleys Schilderung von Einschätzungen aus dem Umfeld des Bun-Teams lässt sich als mangelnde Kommunikation, unrealistische Erwartungen, geringe Empathie und fehlende Erfahrung zusammenfassen, hat aber die Grenze von Hörensagen
  • Dennoch passt diese Einschätzung zu dem extremen Arbeitsumfeld, das bereits in der Stellenausschreibung öffentlich beschrieben wurde
  • Auch in einem schlechten Arbeitsumfeld kann hervorragende Technik entstehen, und Bun selbst ist ein brauchbares und interessantes Tool
  • Die Einschätzung, der Code habe viele Bugs enthalten und sei schwer wartbar gewesen, ist nicht nur externe Kritik, sondern genau der Zustand, den Bun selbst als Begründung für den Rust-Wechsel angeführt hat

Der praktische Wert eines unsafe-Rust-Portierungsansatzes

  • Die technischen Details des Übergangsprozesses sind es wert, auch in anderen Modernisierungsprojekten wiederverwendet zu werden.
  • Bun hat keine komplette Neugestaltung in sicherem Rust von Grund auf vorgenommen, sondern eine dateibasierte Portierung in unsafe Rust durchgeführt.
    • Dadurch blieb die bestehende Struktur erhalten und das anfängliche Risiko der Umstellung wurde reduziert.
    • Zugleich wurde eine Grundlage geschaffen, um später die Sicherheit zu verbessern und neu zu entwerfen.
  • KI-basierte Automatisierung könnte die Sprachwahl leichter revidierbar machen als früher, doch automatisches Umschreiben hat weiterhin Vor- und Nachteile sowie semantische Unterschiede.
  • Es ist auch möglich, mehrere Umschreibungsverfahren zu kombinieren und sie mit Formal Methods zu verstärken.
  • TRACTOR von DARPA ist ein Forschungsprogramm zur Übertragung sämtlichen C-Codes nach Rust; der veröffentlichte Evaluierungsbericht behandelt den Stand der Technik bei automatisierter Transformation.
  • Selbst wenn Agenten für alten Code mehr Optionen bieten, bleiben Urteilsvermögen und Kommunikation nötig, um Modernisierungsziele festzulegen.

Ein technisches Entscheidungsdokument mit vielen Lücken

  • Um eine technische Entscheidung zu erklären, braucht es mindestens drei Elemente.
    • Was war die Motivation?
    • Welche Alternativen wurden geprüft?
    • Was sind die Vor- und Nachteile jeder Alternative?
  • Das Dokument, in dem Richard Feldman seine Gründe für die Portierung des Roc-Compilers von Rust nach Zig zusammenfasst, ist ein Vergleichsfall, der alle drei Elemente enthält.
  • Buns Erklärung nennt Speicherfehler als Motivation, behandelt die geprüften Alternativen jedoch nur teilweise, und ein Vergleich der Vor- und Nachteile fehlt faktisch.
  • Gerade wenn Vor- und Nachteile ausgelassen werden, kann es so wirken, als sei die Antwort von Anfang an festgestanden und die Begründung erst nachträglich ergänzt worden.
  • Es lässt sich auch nicht ausschließen, dass es weitere, nicht veröffentlichte Gründe gab; um die Glaubwürdigkeit der Entscheidung zu erhöhen, sollten auch die nachteiligen Kosten offengelegt werden.

Ein Vergleich, der nur die Vorteile von Rust aufzählt

  • Der Abschnitt „Bun is better in Rust“ behandelt nur die Vorteile des Wechsels zu Rust und nennt die Kosten kaum.
  • Große Rust-Codebasen zahlen für die gewonnene Sicherheit typischerweise den Preis langsamerer Compile-Zeiten.
  • Bun maß der Kompiliergeschwindigkeit in der Vergangenheit große Bedeutung bei und versuchte, durch einen Fork des Zig-Compilers eine 4-fache Beschleunigung zu erreichen.
  • Wenn die Build-Zeiten für Mitwirkende durch die Rust-Portierung gestiegen sind, sollte das offengelegt werden; zudem sollte erklärt werden, warum Sicherheit wichtiger ist als dieser Preis, damit die Entscheidung glaubwürdiger wird.
  • Wenn andere Verbesserungen nach der Umstellung in die Liste der Vorteile der Rust-Neuschreibung aufgenommen werden, kann der direkte Effekt des Sprachwechsels übertrieben erscheinen.

Nicht geprüfte Optionen bei Style Guides

  • Speicherfehler waren bei Bun nicht die einzige Fehlerursache, traten laut einer privaten Auswertung aber so häufig auf, dass vier Fix-Commits pro Woche nötig waren.
  • Jeder Speicherfehler bedeutet, dass irgendwo Regeln darüber gebrochen wurden, wie Objekte erzeugt, besessen und freigegeben werden; deshalb könnte man zunächst prüfen, wie sich erwartete Verhaltensweisen je nach Situation klarer festlegen lassen.
  • Manuelles Speichermanagement erweitert den Geltungsbereich solcher Regeln, erfordert aber sprachunabhängig wirksame Nutzungsvorgaben; auch Rust hat API-Style-Guidelines.

  • TigerBeetle als gezeigte Alternative

    • TigerBeetle, eine weitere prominente Zig-Codebasis für eine Finanztransaktionsdatenbank, leidet nicht unter Speicherfehlern und wirkt wie eine der zuverlässigsten Datenbanken überhaupt.
    • Es stützt seine Zuverlässigkeit auf TigerStyle und Simulationstests.
    • TigerStyle ist nicht bloß ein einfaches Codierungsschema, sondern eine Engineering-Philosophie, die Design, Speicher und Tests zusammenführt.
    • Der gesamte Speicher wird beim Start statisch allokiert.
    • Nach der Initialisierung sind weder dynamische Allokation noch Reallokation nach Freigabe erlaubt.
    • So werden use-after-free-Fehler verhindert, ohne unvorhersehbare Leistungsschwankungen in Kauf zu nehmen.
    • Mögliche Speichermuster werden bereits in der Entwurfsphase berücksichtigt, was zu einfacheren, schnelleren und leichter nachvollziehbaren sowie wartbaren Strukturen führt.
    • Nicht jede Anwendung kann diesen Ansatz unverändert übernehmen, aber er zeigt, dass Speicherpolitik mit den gesamten Architekturentscheidungen verknüpft ist.

  • Offene Fragen in Buns Erklärung

    • Bun erwähnt TigerStyle und Googles 31.000 Wörter umfassenden C++-Style-Guide und fasst dann zusammen, Style Guides seien schwer durchzusetzen und stützten sich traditionell auf Code Reviews, Linter und statische Analysewerkzeuge.
    • Es wird jedoch nicht behandelt, welchen Style Guide Bun tatsächlich verwendet hat, warum er scheiterte und wie er über vier Jahre hinweg verbessert wurde.
    • Wenn Speicherprobleme in einem großen Projekt fortbestehen, ist entscheidend, ob Alternativen ernsthaft getestet wurden, bei denen die aktuelle Sprache anders genutzt wird; dafür fehlt jedoch belastbare Evidenz.
    • Eine Arbeitsweise, bei der eine einzelne Person den gesamten Kontext im Kopf behalten soll und keine Meetings stattfinden, erschwert die Schaffung expliziter Regeln und eines gemeinsam getragenen Designs.

Der Widerspruch zwischen Agenten-Review und Style Guides

  • Bun hält Style Guides für schwer durchsetzbar, erklärt aber zugleich, PORTING.md für die Migration geschrieben zu haben und dass Agenten den gesamten umgeschriebenen Code anhand strenger Vorgaben überprüft hätten.
  • PORTING.md selbst ist ein auf den Umfang der Umstellung spezialisierter Style Guide; wenn das Agenten-Review erfolgreich war, wäre das Problem der Durchsetzung von Richtlinien damit bereits gelöst.
  • Unter geeigneten Bedingungen kann Agenten-Review funktionieren, setzt aber ausreichend durchdachte Regeln und Review-Verfahren voraus.
  • Dieselbe geistige Anstrengung hätte auch in die Neugestaltung des Zig-Codes und die Verschärfung von Regeln investiert werden können, doch Bun entschied sich für Umschreiben statt Re-Architektur.
  • Aus mehreren nicht veröffentlichten Gründen mag das Umschreiben die richtige Wahl gewesen sein, aber die derzeitige Erklärung reicht für einen ausreichenden Vergleich der Alternativen nicht aus.

Eine Million Zeilen Umschreibung und drei Zeilen Pointer-Code

  • Bun argumentiert, dass zur Abbildung von Ownership-Erwartungen auf Typebene in Zig zusätzlicher Code wie SharedPtr(TCPSocket) und deref() nötig wäre und dies weniger bequem sei als die bisherige Nutzung von Pointern.
  • In diesem Beispiel würde der Code an den Schnittstellengrenzen um ungefähr drei Zeilen wachsen, um die Übergabe von Pointern klarer zu machen.
  • Es wirkt inkonsequent, KI-generierte PRs im Umfang von einer Million Zeilen zu akzeptieren, die kaum zu prüfen sind, zugleich aber einige Zeilen zur Klarstellung von Pointer-Ownership mit Verweis auf Lesbarkeitsprobleme abzulehnen.
  • Jarred Sumner hat bereits erklärt, dass über Monate hinweg kein Mensch den Code direkt eingegeben habe.
  • Wenn Code nicht für Menschen gedacht ist, wird das Argument schwächer, dass ein SharedPtr-Wrapper unangenehm anzusehen sei; wenn er aber für Menschen gedacht ist, müssen Lesbarkeit, Prüfbarkeit und Wartbarkeit weiterhin berücksichtigt werden.
  • KI-Unternehmen tun sich schwer damit anzuerkennen, dass Codelesbarkeit weiterhin wichtig ist; sie zu leugnen passt zwar zur Erzählung vom Ende des Software Engineerings, kollidiert aber mit der Realität der Wartung.
  • Es gibt auch Benchmarks, denen zufolge Coding-Agenten die Wartbarkeit standardmäßig verschlechtern können.

Dasselbe Beispiel zeigt: „AI allein reicht nicht“

  • Die groß angelegte Neuschreibung des Agenten in Bun dient nicht nur der technischen Verbesserung, sondern erfüllt auch eine geschäftliche Funktion, indem Anthropic die Botschaft bewirbt, dass „AI ausreicht“
  • Dasselbe Beispiel lässt sich jedoch auch genau gegenteilig interpretieren
  • Unter der Annahme, dass sich selbst von Agenten verursachte Probleme mit noch mehr Agenten lösen lassen, verbreitet sich der Ansatz, Tokens zu kaufen statt bessere Werkzeuge zu bauen und SKILL.md anzuhängen statt Technik zu erlernen
  • Statt die Psychologie von Software-Teams zu verstehen, werden parallele Agent-Sessions als Team bezeichnet, was menschliche Organisationen mit automatisierten Ausführungssitzungen verwechselt

Die Einführung von Coding-Agenten und die Abschaffung von Engineering sind nicht dasselbe

  • Anthropics Kampagne vom Ende des Software Engineerings kann sowohl für die Hersteller von AI-Tools als auch für deren Nutzer kontraproduktiv sein
  • Auch wenn Coding-Agenten eingeführt werden, muss man nicht die Dark Software Factory als Idealmodell betrachten, in der Menschen den Code nicht verstehen
  • Das Ziel ist, Dinge zu bauen, die Menschen wollen und die zuverlässig funktionieren; die AI-Blase kann dagegen dazu drängen, Unerwünschtes in niedriger Qualität zu produzieren
  • Erforderlich ist ein Weg, AI zu nutzen, ohne Urteilsvermögen, Lernen, Kommunikation, Lesbarkeit und Wartbarkeit aufzugeben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Meinungen auf Hacker News

  • In diesem Beitrag steckt viel Gutes, aber er erinnert mich an KI-generierte Projekte, die nach ein paar Monaten aufgegeben werden. Der Wert eines Projekts liegt weniger in der Menge des generierten Codes als darin, wie stark es in der Praxis erprobt wurde, und reifer bestehender Code ist besser als eine neue Neufassung
    Die bestehende Zig-Codebasis ist bereits erprobt, während die Rust-Neufassung außer bestandenen Tests nahezu keine Validierung hat. Wenn sie Datei für Datei als direkte Übersetzung in unsafe Rust umgesetzt wurde, ist zudem unklar, was daran besser sein soll als Zig als Ausgangspunkt. Erst wenn sie später in sicheres Rust überführt und durch Produktionsumgebungen sowie viele Nutzer validiert wird, gewinnt das an Bedeutung
    Im Grunde ist Bun damit geforkt worden; ob die Zig- oder die Rust-Version überlebt, ist egal, und es gibt keinen Grund, das als Problem der Eignung von Zig zu verstehen

    • KI-Projekte werden aufgegeben, weil sie spontan generiert werden. Versunkene Kosten können im Gegenteil ein Vorteil sein, der einen durch Widrigkeiten und Durststrecken trägt, aber zu einem Ergebnis, das nur aus einer spontanen Idee und einem Claude-Prompt entstanden ist, entwickelt man keine Bindung
      Selbst ich als durchschnittlicher Programmierer habe jeden Tag Dutzende toller Ideen, aber nur extrem wenige halten einer Prüfung stand, und ein paar Tage später erscheinen selbst diese nicht mehr der Mühe wert. Ideen waren schon immer billig, und jetzt sind sogar Proofs of Concept billig geworden; ein Show HN, in das nicht einmal ein Monat investiert wurde, interessiert mich daher nicht
    • Um zu sicherem Rust zu gelangen, das umfangreich in der Praxis erprobt wurde, muss man irgendwo anfangen; deshalb hat man sich entschieden, zunächst direkt zu übersetzen und dann schrittweise zu verbessern
      Das Zig-Lager scheint zu befürchten, dass Zig vielleicht von Anfang an eine chancenlose Sprache ist, weil sie gegenüber C nicht genügend Vorteile bietet, um ernsthaft eingesetzt zu werden, und sogar ihr Vorzeigeprojekt sie verlassen hat. Wer im Zig-Issue-Tracker nach segfault sucht, versteht, warum man angesichts von Alternativen wie Rust an ihrem künftigen Nutzen zweifeln kann
    • Anders als bei Zig gibt es nun klare und eng begrenzte unsafe-Grenzen, die man eine nach der anderen beheben kann; das ist besser
    • Die Einleitung des Beitrags ist übermäßig zynisch. Wenn ich mir Bekannte bei Anthropic und OpenAI ansehe, glauben sie tatsächlich, dass in naher Zukunft Agenten den Großteil der Programmierung übernehmen und sie selbst ihre Jobs verlieren werden
      Sie steuern ihre Botschaft nicht, um das Anti-KI-Lager zu belehren
    • Man kann nicht einfach behaupten, KI-generierte Projekte würden wegen mangelnder Praxiserprobung schnell aufgegeben. Auch gewöhnliche persönliche Projekte werden meist nach einiger Zeit aufgegeben, und wenn man Code viel schneller schreiben kann, erreicht man den Punkt des abnehmenden Grenznutzens bei persönlichem Nutzen, Lernen und Spaß vielleicht einfach früher

  • Größer als die Tatsache, dass Andrew sich unverblümt geäußert hat, ist das Problem der Doppelmoral des Textes: Er ist offensichtlich ein persönlicher Angriff und behauptet zugleich, keiner zu sein
    Nachdem ich diesen Text gelesen habe, habe ich keine Lust mehr, etwas mit Zig zu bauen. Egal welche technische Entscheidung man trifft: Der auf Lebenszeit wohlwollende Diktator (BDFL) von Zig kann solche Texte schreiben; es ist schwer vorstellbar, dass sich die Führung anderer Communities wie Python oder Rust so verhält

    • Noch problematischer ist, dass sich diese Haltung in der Zig-Community auszubreiten scheint. Auch wenn es noch nicht die Mehrheit ist: Wenn freundliche Menschen in wärmere Communities abwandern, steigt der Anteil dieser Tendenz in der verbleibenden Gruppe
    • Ich möchte Andrew verteidigen: Er legt aufrichtig Wert darauf, das Richtige zu tun, und hat deshalb starke Ansichten, aber er ist geduldiger und inklusiver, als es aus der Ferne wirken mag
      Manche sehen Andrews Text als Angriff auf Bun, und ich könnte die Reaktionen auf Andrew als persönliche Angriffe sehen. Wenn man die Vorurteile beiseitelässt, muss man entweder sagen, dass beide Seiten falsch lagen oder dass keine Seite falsch lag; man sollte sich bewusst sein, dass persönliche Vorannahmen einen viel zu großen Einfluss haben, wenn man eine Situation aus der Ferne beurteilt
    • Es wäre in Ordnung, solange man beim Weggehen keinen irreführenden Text schreibt, der Zig schlecht aussehen lässt, und nicht ohne Nachricht einem vereinbarten Treffen mit der Zig Foundation fernbleibt
    • Andrews Text wurde mehrfach überarbeitet; wenn man die neueste Fassung liest, könnten sich die Bedenken vielleicht erledigen: https://github.com/andrewrk/andrewkelley.me/commits/master/p...
    • Rust hat vom Design her keinen BDFL, und soweit ich mich erinnere, hat sich auch Python von diesem Modell entfernt. Einzelne Beitragende können wütend werden und aggressive Texte schreiben, aber es gibt keine einzelne Person, die die Sprache so repräsentiert wie bei Zig

  • Ich möchte auf Andrews Seite stehen. Nachdem ich Sumners Arbeit über Jahre verfolgt habe, ist Kelleys Kritik zwar unfreundlich, aber zu einem großen Teil zutreffend, und selbst wenn das Ergebnis nützlich und beeindruckend ist, wirkte es von Anfang bis Ende eher wie Einflussnahme zur Selbstvermarktung
    Auch ich betreibe täglich acht Stunden agentenbasierte Entwicklung und habe meinem Team empfohlen, Rust und Deno statt Node zu verwenden, aber diese Neufassung war schlecht begründet und wirkt wie die Fortsetzung einer langen PR-Kampagne, die Dario und seine Leute erfolgreich durchgezogen haben. Wäre die Formulierung höflicher gewesen, wäre sie gut aufgenommen worden; trotzdem schätze ich, dass er statt eines vom PR-Team ghostgeschriebenen Textes seine ehrlichen Gedanken vorgelegt hat

    • Die Lehre aus diesem Aufruhr ist, dass man eine hitzige Antwort vor dem Veröffentlichen ein bis zwei Tage liegen lassen und engen Freunden zeigen sollte. Es wäre besser, wenn Andrew eine Schlussfolgerung in der Art der später von ihm korrigierten Fassung schon in der ersten Überarbeitung veröffentlicht hätte
    • Die Vorabbegründung für die Neufassung war schwach, aber auch ohne Beispiele war nachvollziehbar, warum Jarred frustriert war
      Die Erklärung, dass die Interaktion mit dem JavaScript-Garbage-Collector Bun vor besondere, eigene Schwierigkeiten stellt, war hilfreich, aber Andrew ging überhaupt nicht darauf ein. Auch die Erklärung, dass der neue Code mit der bestehenden Testsuite validiert wurde, räumte das Missverständnis aus, die Tests seien ebenfalls per Vibe Coding übersetzt worden und daher nicht vertrauenswürdig. Dass Tests nicht alle Bugs finden, gilt für jede Software, Zig eingeschlossen
      Letztlich prallten hier die Sichtweise, dass speicherunsichere Sprachen enorme Fehlerkosten verursachen, und die Reaktion „werde besser und schreibe keine Bugs“ aufeinander; hinzu kamen die KI-Debatte, Anthropics Beteiligung und Andrews Linus-artige Ausdrucksweise, wodurch es sich ausweitete
    • Schon die Denkweise, man müsse eine Neufassung gegenüber irgendjemandem außerhalb des Unternehmens rechtfertigen, ist seltsam
    • Bei technischen Themen ist mir eine Haltung wie bei Linus lieber, die Dinge direkt auszusprechen, statt PR-Floskeln zu verwenden; PR-Sprache kann man für nichttechnische Kunden benutzen

  • Ich frage mich, ob Anthropic und Andrew Kelleys Text hier auf dieselbe Weise gelesen wurden. Anthropic ist kein Unternehmen, das Programmiersprachen verkauft, und Buns Beitrag zur Neuschreibung in Rust enthielt viele technische Details dazu, wie sich das Produkt für Endnutzer verbessert hat.
    Die Reaktion aus dem Zig-Umfeld wirkt dagegen eher wie eine bissige Kolumne voller persönlicher Angriffe. Ich nutze Codex, habe weder an Zig noch an Rust ein Interesse und beobachte das Ganze von außen.

    • Anthropic hat eindeutig ebenfalls Interessen am Markt für Programmiersprachen. Wenn KI das Umschreiben in eine bestimmte Sprache erleichtert, verknüpfen Erfolgsgeschichten diese Sprache mit dem KI-Unternehmen; und ein Rust-Erfolg, der sich leicht mit KI schreiben lässt, nützt auch Anthropic.
      Außerdem werden bei der Vermarktung erfolgreicher Rewrites oft Aspekte ausgeblendet, die der Erzählung schaden würden, etwa wie schlecht der bestehende Code war; auch diesmal fehlen wichtige Punkte.
      Andrew Kelleys Text (https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...) behandelt Jarreds niedrige Engineering-Standards, schwache Außenbeziehungen wie das Nichterscheinen zu Meetings mit der Zig Foundation ohne vorherige Absage, den Schaden, der dadurch entstand, dass Zig im Zuge des Wechsels zu Rust als schlechte Wahl dargestellt wurde, sowie die daraus folgende Verärgerung der ZSF.
      Oberflächlich betrachtet kann man die Sorge haben, dass der Schöpfer einer Sprache einen ehemaligen Nutzer angreift; aber Kelley hat erklärt, warum dieser Eindruck, den auch ich nach der Lektüre von Buns Beitrag hatte, unfair ist. Einige persönliche Angriffe sind allerdings eindeutig, und der später hinzugefügte letzte Abschnitt geht ebenfalls darauf ein.
    • Stellt euch vor, ein Studio wechselt von Unity zu Unreal, und Unity veröffentlicht daraufhin einen Beitrag, der die Qualität des bestehenden Codes und die Arbeitsbedingungen angreift. Dann wirkt schon die Tatsache, dass Zig überhaupt reagiert hat, seltsam.
    • Das ist der alte Konflikt zwischen Handwerkertum und Industrialismus. Andrew gehört zu einer Tradition, die will, dass alle Entwickler stolze Handwerker sind.
      Java, JavaScript, Python und C# haben die von C++ dominierte Industrie erobert, weil sie Sicherheitsgeländer bieten, mit denen auch nicht perfektionistische Entwickler arbeiten können, ohne große Unfälle zu verursachen. Die Performance-Vorteile von C und C++ waren groß, verlangten aber in einer zunehmend feindlichen Umgebung erhebliche Erfahrung.
      Rust und Swift boten eine besser vorhersagbare Performance als Garbage-Collection-Sprachen und zugleich eine ähnliche oder stärkere Sicherheit; Rusts Ideen haben in diesem Bereich eine Explosion neuer Sprachen ausgelöst. Viele davon sind allerdings näher am Handwerkertum als Rust, das stärker aus industriellen Anforderungen heraus entstand.
      Als Auto-Analogie: Java, JavaScript usw. sind normale sichere Fahrzeuge, C/C++ sind Zweirad-Motorräder, Rust ist ein schnelles Rallyeauto, das seine Insassen schützt, und Zig ist eher ein Quad oder ein Open-Wheel-Kart. Es rutscht vielleicht nicht leicht weg, aber wenn es sich überschlägt, ist es sehr gefährlich.
      Handwerker, die Zeit- und Kostengrenzen ignorieren, glauben, man brauche nur vorsichtige Entwickler. In der Industrie kann man zwar guten Code schreiben, aber 90 % der Arbeit findet unter Einschränkungen statt, sodass man weder eigenem noch fremdem Code leicht vertrauen kann. Zig hat viele Vorzüge, war aber von Anfang an eine Sprache für Menschen, die Hacker-Freiheit der Sicherheit vorziehen.
    • Verbesserungen bei Binärgröße und Geschwindigkeit haben wenig mit der Neuschreibung in Rust an sich zu tun und wären wohl auch mit vergleichbarem Aufwand in der Zig-Codebasis möglich gewesen. Teilweise wurde zusätzliche Arbeit investiert, damit diese Zahlen zur Bewerbung des Rewrites gut aussehen.
      Auch Memory Safety hätte man ähnlich erreichen können, wenn das Zig-Team den integrierten Fuzzer, den es angekündigt hatte, genutzt hätte, statt KI, Tests und höherstufiges Fuzzing. Trotzdem kann das reifere Rust für ein Projekt wie Bun die bessere Wahl sein.
      Andrews Perspektive war unverzichtbar, um zu verstehen, was passiert ist. Manche Formulierungen hätten milder sein können, aber wenn schlechtes Management die direkte Ursache für beschädigte Beziehungen und mangelhafte Engineering-Ergebnisse ist, dann ist das offenzulegen kein persönlicher Angriff, sondern notwendiger Kontext.
    • Es ist kurzsichtig, ein Produkt, das Code für einen schreibt und so die Produktivität von Programmierern steigern soll, nur deshalb als unabhängig vom Sprachenmarkt zu betrachten, weil es keine eigene Sprache verkauft.
      Insbesondere lehnt die Zig-Führung Vibe Coding öffentlich ab und kritisiert die Branche; das Projekt weist Contribution Requests zurück, die mit solchen Produkten erstellt wurden.

  • In dieser Debatte fehlt es eigentlich an technischer Substanz. Buns Rust-Portierung, Andrews aggressiver Beitrag oder Anthropic als Schaufelverkäufer im Goldrausch interessieren mich nicht; ich möchte konkrete technische Inhalte sehen.
    Jarreds Gründe für den Wechsel zu Rust wirken trotz etwas dünner Begründung plausibel, aber Andrew hat nicht widerlegt, warum das keine echten Probleme seien oder wie man sie in Zig idiomatisch lösen würde. Besonders wünschenswert wäre eine Analyse der Punkte anhand des tatsächlichen Zig-Codes von Bun.

    • Betrachtet man nur die von Bun vorgelegten Fakten, fehlt dem Rewrite die technische Tragfähigkeit, und da Rewrites in den meisten Fällen schlechtes Engineering sind, ist das nicht überraschend.
      Bun wurde trotz enormem Umfang und hoher Komplexität von jemandem begonnen, der wenig Zig-Erfahrung hatte, und war von Anfang an ein Projekt, das Code aus anderen Sprachen neu schrieb. Wenn man den JavaScript-/TypeScript-Transpiler von esbuild zeilenweise von Go nach Zig überträgt und dann nach ein paar Jahren die gesamte Codebasis verwirft, um sie erneut in einer anderen Sprache zu schreiben, fragt man sich, was es da noch zu diskutieren gibt.
    • Andrews Kernpunkt lautet, dass Buns Code von Anfang an schlecht war, und es liest sich so, als deute er an, Jarred sei eine schädliche Person, mit der sich diese Debatte gar nicht lohne.
    • Bun will sich schnell bewegen und Dinge kaputtmachen, während Zig zu langsamem, vorsichtigem Vorgehen zwingt.
      Bun will Features wie eine Shell-Sprache oder SQLite-/PostgreSQL-Clients so schnell wie möglich ausliefern und möchte sich daher nicht selbst um Speicherverwaltung kümmern. Zig zwingt einen, Speicherverwaltung und Lebensdauern direkt zu behandeln, und fügt bewusst keine Features wie Drop hinzu; Rust passt dank Drop besser.
      So wie man keine SQL-Datenbank in Python schreibt, ist Zig nicht das passende Werkzeug für Bun; das ist weniger eine Frage einer idiomatischen Lösung in Zig als ein Unterschied in Jarreds Art, das Projekt schnell voranzutreiben.
    • Der Originaltext spricht dieses Problem direkt an, wählt aber fast nur die positiven Aspekte aus. Wenn man etwa sagt, man habe sogar den Zig-Compiler neu geschrieben, um Build-Zeiten zu verbessern, fragt man sich, warum die im Allgemeinen deutlich langsameren Rust-Build-Zeiten überhaupt nicht behandelt wurden.
    • Diejenigen, die im Goldrausch Schaufeln verkaufen, sind die Unternehmen, die Rechenzentren und Energie bauen; Tokens sind das Gold.

  • Einigen von Kelleys Ansichten stimme ich zu, aber das Problem ist der Ton.
    Wenn Bun von Rust nach Zig umgeschrieben worden wäre, hätte wahrscheinlich kein Mitglied des Rust-Core-Teams einen Beitrag mit persönlichen Angriffen auf Sumner geschrieben und zugleich behauptet, es sei kein Angriff. So wie Kelley die Freiheit hat, den Beitrag zu schreiben, den er schreiben möchte, haben andere die Freiheit, auf das öffentliche Bild von Zig zu reagieren, das der BDFL einer wachsenden Sprache geprägt hat.

  • Der Beitrag über Buns Wechsel zu Rust ließ konkrete Vergleiche der Optionen und Zahlen zu den Auswirkungen vermissen und stellte das Ergebnis voreingenommen dar; er fühlte sich nicht wie ein Engineering-Blogpost an.
    Die Leute schienen sich eher für den Einsatz von Agenten als für die technischen Gründe der Portierung zu interessieren, und technisch war das sehr enttäuschend.

    • Ich frage mich, ob wir denselben Beitrag gelesen haben. Er behandelte zwar keine einzelne konkrete Codezeile, enthielt aber wiederholt tiefe Architekturdetails, Begründungen zu Speichersicherheit und Bugs sowie Coding-Muster mit Agenten im großen Maßstab.

  • Man sollte nicht unterschätzen, wie groß der Einfluss von Marketing auf Führungskräfte und Executives ist, und insbesondere, wie sehr Menschen in Positionen wie der eines CEO von kleinlichen Emotionen getrieben sein können.
    Allein die Gelegenheit, das neue Fable-Modell zu bewerben, und die Tatsache, dass Zig sich öffentlich gegen die Nutzung von Anthropic-Produkten stellt, könnten praktisch schon ausgereicht haben, um Buns Rust-Rewrite zu besiegeln.

    • Ich sehe keinen Grund anzunehmen, dass das Management in irgendeiner Form eingegriffen hat. Viel plausibler ist, dass Jarred einfach getan hat, was er selbst wollte, und genau das hat er auch immer gesagt.

  • Ich verstehe nicht, warum in einer Debatte über den Sprachwechsel sogar Erwartungen an Arbeitszeiten behandelt werden. Selbst wenn er ein schlechter Manager wäre, wirkt es so, als würde man krampfhaft nach negativem Material suchen.
    Bezeichnend ist auch, dass die Zig-Seite sich kaum auf die technischen Vorteile des Rewrites selbst konzentriert. Anthropic hat mehrere Verbesserungen angeführt, aber es ist schwer, auch nur einen Versuch zu finden, diese zu widerlegen.
    Wenn mein Projekt mit einem großen Sprachmodell neu geschrieben würde und dabei Verbesserungen ohne Nachteile herauskämen, würde ich sehr besorgt reagieren und darauf eingehen; hier diskutiert man stattdessen abwegig über Arbeitszeiten.

  • Zwischen einem Projekt im Besitz von Anthropic und der Führung einer Sprach-Community, die KI-generiertem Code öffentlich feindlich gegenübersteht, besteht ein offensichtlicher Interessenkonflikt.
    Andrew Kelley hätte es besser dabei belassen sollen, genau das zu sagen; seine Einschätzungen zur Energie und Motivation des Bun-Gründers tragen kaum etwas Wertvolles bei.

    • Für die Lager, die KI absolut befürworten oder ablehnen, ist ein Kompromiss schwierig. Die meisten technischen Argumente und Angriffe sind nachträgliche Rationalisierungen; je nach Organisation unterscheiden sich einfach Kontext und Ziele.
      Kelley wusste das wohl auch, konnte aber der Versuchung offenbar nicht widerstehen, den Kernpunkt zu verwässern. Der scharfe Beitrag ([0]: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...) ging zu weit, aber der Anhang, der zum Weitermachen aufruft, ist vernünftig. Ich denke, ein BDFL sollte lieber etwas würziger sein als allzu fade.