4 Punkte von GN⁺ 8 시간 전 | 2 Kommentare | Auf WhatsApp teilen
  • Zig-Schöpfer Andrew Kelley interpretiert Buns Neuschreibung in Rust nicht als Frage von Sieg oder Niederlage von Sprachfeatures, sondern als einen Vorfall, der den Zusammenbruch der Beziehung zwischen der Zig Software Foundation (ZSF) und Bun/Oven offenlegt
  • Das frühe Bun erkannte Zig als Grundlage seiner Performance-Erfolge an und spendete jährlich 60.000 US-Dollar an die ZSF, doch nachdem es zu einem VC-finanzierten Startup geworden war, nahmen Unzufriedenheit mit Organisationsführung und Codequalität zu
  • Die ZSF sorgte sich im Bun-Codebestand über hackige Implementierungen, übermäßigen Einsatz von Assertions und darüber, dass im Vergleich zu schneller Feature-Entwicklung zu wenig Zeit in Bugfixes und den Abbau technischer Schulden floss; auch dass Bun wie ein Vorzeigeprojekt für Zig wirkte, wurde als Belastung empfunden
  • Kelley kritisiert, dass der Text zu Buns Wechsel auf Rust sinkende Bugzahlen als Gegensatz von Styleguide vs. Sprachfeatures darstelle, während der eigentliche Kern für ihn in der für Bugbeseitigung eingesetzten Engineering-Zeit und im Management der Codequalität liege
  • Die ZSF sei zwar dankbar für Buns Spenden, doch nach der Übernahme durch Anthropic endeten Spenden und Beziehung; dass die geschäftlichen Interessen von Zig und Bun durch die Rust-Neuschreibung nun getrennt seien, werde positiv aufgenommen

Die frühe Beziehung zwischen Bun und Zig

  • Jarred stieß vor etwa fünf Jahren zur Zig-Community, und Kelley sah in ihm jemanden mit starker „beginner energy“, der schnell ausprobiert und viel lernt
  • Als Bun als JavaScript-Toolchain Aufmerksamkeit bekam, wuchs auch das Interesse an Zig
  • Kelley meint, Jarred hätte allein durch Crowdfunding ein für San Francisco stabiles Einkommen erzielen können, glaubt aber, dass er sich im Geist des Thiel Fellowship und des Silicon-Valley-Ansatzes für Venture Capital entschied
  • Das frühe Bun stand dem Zig-Projekt positiv gegenüber
    • Auf der Bun-Website wurde Zig für die Performance-Ergebnisse gewürdigt
    • Es wurden monatliche Spenden in Höhe von insgesamt 60.000 US-Dollar pro Jahr an die Zig Software Foundation eingerichtet
    • Auch im Text zur Rust-Neuschreibung von Bun wirke der Dank an das Zig-Projekt aufrichtig

Risse nach der Entwicklung zum VC-finanzierten Startup

  • Nachdem Bun zu einem VC-finanzierten Startup geworden war, entwickelte sich Jarred von einem Entwickler, der mit der Community Open Source aufbaut, eher zu einem Geschäftsbetreiber
  • In Ovens Recruiting-Botschaften wurde für die ersten rund neun Monate eine hohe Arbeitsintensität angekündigt, und es hieß, wer unter Work-Life-Balance verstehe, viel Zeit nicht zu arbeiten, passe womöglich nicht dazu
  • Kelley sagt, er habe in Gesprächen mit Bewerbern und Mitarbeitern von Oven wiederholt negative Einschätzungen zu Jarreds Rolle als Manager gehört
    • Genannt wurden dabei mangelnde Kommunikation, unrealistische Erwartungen, geringe Empathie und fehlende Erfahrung
  • In der Folge mieden Community-Mitglieder, die eigentlich mit Zig arbeiten wollten, Oven und Bun
  • Je stärker sich Jarred auf Produktivität und Startup-Exit-Strategien konzentrierte, desto weiter entfernte er sich von Kelleys langfristiger Vision für Zig
    • So habe Jarred etwa gefordert, die Implementierung des Language Server Protocol und die VSCode-Integration zu priorisieren, während Kelley größere Pläne verfolgte

Von der ZSF wahrgenommene Probleme mit Buns Codequalität

  • Das zentrale Problem, das Kelley nennt, ist die Codequalität
  • Das Zig-Team liest den Quellcode von Nutzerprojekten, prüft, wie sich Sprachänderungen auf Nutzer auswirken, und testet Brüche sowie Performance-Regressionen, die durch Änderungen entstehen
  • Im Bun-Codebestand nahmen Programmierpraktiken zu, die der ZSF Sorgen bereiteten
    • hackige Implementierungen häuften sich weiter an
    • es gab übermäßigen Einsatz von Assertions
    • im Verhältnis zur schnellen Einführung neuer Features blieb wenig Zeit für Reflexion, Bugbeseitigung und den Abbau technischer Schulden
  • Kelley befürchtete, dass diese Arbeitsweise von Bun mit Kritik an der Speichersicherheit von Zig verknüpft werden könnte, und wollte zum Zig-Projekt sozial Abstand halten
  • Die ZSF versuchte, Bun zu besseren Programmierpraktiken zu bewegen, hatte damit aber keinen Erfolg

Die Übernahme durch Anthropic und die Rust-Neuschreibung

  • Innerhalb der ZSF entstand die Einschätzung, dass Bun eher eine Nettoverbindlichkeit (net liability) sei
  • Dass Bun wie ein repräsentatives Beispiel für Zig wirkte, war belastend, obwohl es in Wirklichkeit eher ein Beispiel dafür sei, „wie man Zig-Code nicht schreibt“
  • Kelley hielt Buns Geschäftsplan, „irgendetwas mit Cloud zu verkaufen“, von Anfang an für schwach und meinte, dass Zig bei einem späteren Verkauf indirekt ebenfalls negative Publicity abbekommen könnte
  • Nach der Übernahme durch Anthropic war die ZSF erleichtert
    • die Spenden wurden stillschweigend eingestellt, womit die ZSF bereits gerechnet hatte
    • von Bun-Seite wurden monatliche Meetings weder abgesagt noch besucht, und die Beziehung galt als beendet
  • Die ZSF vermutete, dass innerhalb weniger Tage eine Rust-Neuschreibung angekündigt würde, und begrüßte das
  • Nach der Anthropic-Übernahme belastete die Zig-Community bereits die indirekte Verknüpfung, dass Claude auf Bun und Bun auf Zig basiere
    • es gab mehr drive-by slop contributions
    • AI-begeisterte Nutzer, die LLM-Ausgaben in Forenbeiträge einfügten, strömten herein
    • Kelley sorgte sich, Zig könnte als mit AI verbundene Programmiersprache bekannt werden
  • Als Jarred die Rust-Neuschreibung ankündigte, begrüßte Kelley das sehr und drückte das Gefühl aus: „nicht mehr mein Problem“

Erwiderung auf Buns Text zur Rust-Neuschreibung

  • Kelley hält den Text zu Buns Rust-Neuschreibung zwar für gut geschrieben, weist aber auf einige zentrale Probleme hin
  • Der Kern sinkender Bugzahlen

    • Der Bun-Text stelle es so dar, als müsse man zur Vermeidung von Bugs zwischen Styleguide und Features der Programmiersprache wählen
    • Für Kelley ist der wichtigste Weg zur Bugbeseitigung, Engineering-Ressourcen einzusetzen, um Bugs zu finden und zu entfernen
    • TigerBeetle habe Zeit investiert, um Bugs zu finden und zu beseitigen, und zugleich eine gesunde Beziehung zur ZSF gepflegt; Bun habe beides nicht getan
  • Widerspruch beim Test-Suite-Argument

    • Kelley versteht den Bun-Text so, dass die Test-Suite als Begründung dafür herangezogen wird, eine Million Zeilen ungeprüften Codes auszuliefern
    • Er fragt dann, warum es im Zig-Code so viele lästige Bugs gegeben habe und weshalb die Test-Suite Bugs im Zig-Code nicht erfasse, aber Bugs in einer Million Zeilen ungeprüften Codes erfassen könne
  • Performance und LTO

    • Der Bun-Text schreibe Performance-Gewinne LTO zu, doch Zig habe LTO während der gesamten Lebensdauer von Bun unterstützt
    • Zig habe LTO früher standardmäßig aktiviert, es wegen zu vieler LLVM-Bugs aber aus den Standardeinstellungen entfernt; diese Bugs beträfen auch Rust
    • Kelley meint, es sei sehr wahrscheinlich, dass die ZSF zur Aktivierung von LTO geraten habe und Bun nicht darauf gehört habe
  • Fuzzing

    • Der Bun-Text deute an, dass für den Zig-Code gewissenhaft Fuzzing betrieben worden sei, doch Kelley sagt, das Bun-Team habe ihm in einem Gespräch erklärt, dass dort überhaupt nichts gefuzzt werde
  • Binärgröße und comptime

    • Der Bun-Text führe mehrere Engineering-Maßnahmen zur Verringerung der Binärgröße als Begründung für die Rust-Neuschreibung an, doch Kelley hält diese Arbeiten für unabhängig von der Neuschreibung selbst
    • Diese Arbeiten seien eher Engineering-Aufgaben, die von Anfang an im Zig-Codebestand hätten erledigt werden sollen
    • Die ZSF habe jahrelang vor dem übermäßigen Einsatz von comptime in Bun gewarnt und sogar eine Time-Report-Funktion geschaffen, um Nutzung von comptime/inline und Kompilierzeiten prüfen zu können
  • Kompiliergeschwindigkeit

    • Kelley weist darauf hin, dass der Bun-Text die Kompiliergeschwindigkeit nicht erwähnt
    • Das Zig-Compiler-Projekt umfasst rund 600.000 Zeilen und ist damit ähnlich groß wie Bun vor der Neuschreibung
    • Laut Kelleys Messung dauert ein vollständiger Build aus sauberem Cache 16 Sekunden, und nach Aktivierung inkrementeller Kompilierung benötigen nachfolgende Änderungen jeweils 90 ms
    • Er fragt, wie die entsprechenden Messwerte für Bun nach der Rust-Neuschreibung aussehen

Kelleys Fazit

  • Für Kelley ist das Kernproblem nicht die Features einer Programmiersprache, sondern der Zusammenbruch einer Beziehung
  • Die ZSF sei aufrichtig dankbar für die von Bun erhaltenen Spenden und habe das Geld für Vergütungen für Zig-Mitwirkende verwendet
  • Kelley betont, dass er Jarred nicht böswillig persönlich kritisieren wolle
    • Jarred habe andere Vorlieben und Lebensziele als er selbst, aber sich erfolgreich das Leben aufgebaut, das er wollte
    • Er erkenne an, dass Jarred glücklich und erfolgreich sei, und hege keinen Groll
  • Kelley freut sich jedoch darüber, dass die geschäftlichen Interessen von ZSF und Bun nicht länger miteinander verflochten sind
  • Wenn die öffentliche Debatte darüber, ob die Rust-Neuschreibung gut oder schlecht sei, als Maßstab für Sprachwahl ende, werde damit auch die Interaktion beider Seiten enden

2 Kommentare

 
click 8 시간 전

Nachdem ich den Artikel gelesen habe, habe ich weder Lust, Zig noch Bun zu verwenden.

 
GN⁺ 8 시간 전
Meinungen auf Hacker News
  • Ich habe beim Lesen von Andrews Code wirklich sehr viel gelernt, und wie im Originaltext gesagt: Ohne Zig hätte es Bun nicht gegeben.
    Zu der Stelle „Im Artikel wird behauptet, Zig-Code gefuzzt zu haben, aber während des Calls sagte das gesamte Bun-Team, dass sie gar nichts fuzzten. Das wirkt wie eine unverhohlene Fälschung“ gibt es einen PR zur Fuzzilli-Integration: https://github.com/oven-sh/bun/pull/24826
    Es gibt auch Merge-PRs, die Probleme beheben, die Fuzzilli im Zig-Code von Bun gefunden hat: https://github.com/oven-sh/bun/pull/28926, https://github.com/oven-sh/bun/pull/28934, https://github.com/oven-sh/bun/pull/29255, https://github.com/oven-sh/bun/pull/29210, https://github.com/oven-sh/bun/pull/29199
    Wenn man nach „Fuzzilli“ sucht, findet man weitere PRs: https://github.com/search?q=repo%3Aoven-sh%2Fbun+is%3Apr+Fuz...

    • Andrew meinte vermutlich zig build test --fuzz, also den in Zig eingebauten Fuzzer; das wäre das Tool, das in seinen Zuständigkeitsbereich fällt.
    • Ich verstehe das nicht ganz. Inwiefern hängt die Aussage „Zig-Code gefuzzt“ damit zusammen, eine Fuzzilli-Integration zu Bun hinzuzufügen?
    • Ich stehe in dieser Debatte nicht wirklich auf einer Seite, aber es wirkt etwas sinnlos, sich aus Andrews Text nur ein bestimmtes Detail herauszugreifen und den Rest gar nicht zu behandeln.
      Ich verehre keinen von beiden; es interessiert mich einfach, weil das ganze Gespräch eher schlechter als besser zu werden scheint.
    • Die Links zeigen zwar, dass ein Fuzzer verwendet wurde, beantworten aber nicht die andere Hälfte von Andrews Aussage. Hat Andrew den Inhalt des Calls falsch wiedergegeben oder falsch erinnert?
      Dass man für eine Frage zur Faktenklärung Downvotes bekommt, ist ziemlich bezeichnend. Es könnte eine einfache Antwort sein wie „Bis vor Kurzem wurde kein Fuzzer benutzt, also haben beide recht“, aber ich weiß es nicht und frage nur deshalb.
  • Dieser Artikel ist unprofessionell und peinlich für Zig.
    Über Jarred weiß ich kaum etwas, aber sein Artikel, den ich gestern gelesen habe, klang dankbar gegenüber Zig, und inzwischen sehe ich, dass er Zig auch eine beträchtliche Summe gespendet hat.
    Dieser ganze Text greift ihn öffentlich und persönlich an, nur weil er sich für ein anderes Produkt entschieden hat.
    Wenn Andrew glaubt, dieser Artikel werde Zig rechtfertigen, ist das seltsam; tatsächlich lässt er Zig nur kindisch wirken. Oder vielleicht will er einfach Jarred angreifen.

    • Ich verstehe nicht, warum es unprofessionell sein soll, auf einem persönlichen Blog zu einem Thema, das einem wichtig ist, eine ehrliche persönliche Meinung zu äußern.
      Muss jeder zu einer wandelnden Marke werden, immer jedes Wort filtern, auf Eierschalen laufen und sich hinter Unternehmensfloskeln verstecken, um „professionell“ zu wirken?
      Die Welt braucht derzeit nicht weniger ehrlichen Diskurs, sondern mehr davon, und Online-Interaktionen scheinen immer weniger authentisch zu werden.
    • Genau. Deshalb sind Anthropic und Bun von Zig weggegangen.
      Zig ist faktisch fast ein Ein-Personen-Projekt, und diese eine Person trifft zunehmend instabile Entscheidungen.
      Natürlich hat er bei seinem eigenen Projekt das Recht dazu, aber ein Unternehmen mit einem Wert von nahezu einer Billion wird sich einem solchen Supply-Chain-Risiko wohl nicht aussetzen wollen.
      Aus Anthropics Sicht ist es besser, das im Keim zu ersticken, sobald klar wird, dass der not-so-BDFL eine Grenze überschreiten könnte, statt weiter in das Zig-Ökosystem zu investieren.
    • Antirez hat ungefähr geschrieben: „Es ist töricht, keine KI zu nutzen, um die Testabdeckung zu erhöhen.“
      Zig dagegen hat, gemessen an Verbreitung und Entwicklungsdauer, eine peinlich niedrige Testabdeckung.
      Zigs Haltung zu KI ist völlig kindisch. Obwohl man stark davon profitieren könnte, wird keine mögliche Nutzung überhaupt geprüft.
      PR-Spam verhindern zu wollen ist etwas anderes, als sich selbst die Hände zu binden und intern KI nicht einmal in den einfachsten, besonders nützlichen Bereichen einzusetzen.
      Man könnte mit KI auch echte Bug-Kandidaten aus PR-Spam herausfiltern; weil man sich aber gar nicht helfen lässt, bleiben echte Bugs länger als nötig liegen.
    • Der Artikel scheint den Wechsel zu Rust eher zu begrüßen. Dieser Punkt wird im Text mehrmals wiederholt, und es wirkt sogar so, als hätte man darauf gewartet und gehofft, dass Bun Zig verlässt.
    • Stimme zu. Dieser Artikel hätte sich auf nüchterne Fakten konzentrieren sollen, statt persönliche Kritikpunkte aufzuzählen, die man am Arbeitsplatz kaum in einem Dokument schreiben könnte.
      Leider gibt es zu viele Open-Source-Entwickler, die sich mit so einem Stil viel zu wohlfühlen, und das ist einer der Gründe, warum ich meine Open-Source-Aktivitäten eingestellt habe.
      An einem vernünftigen Arbeitsplatz würde man für ein solches Verhalten entlassen oder zumindest disziplinarisch belangt werden.
  • Der Satz „Es gibt keine persönliche Kritik an Jarred“ ist ziemlich stark, wenn er am Ende eines Textes steht, der fast vollständig wie kaum verhüllte persönliche Kritik wirkt.
    Jemandem Anfänger-Energie zuzuschreiben und das mit falscher Positivität als jemand zu verpacken, „der scheitert und daraus lernt“, oder zu schreiben, er werde gerüchteweise als „stinkender Manager“ bezeichnet – so etwas.
    Das kommt eher rüber wie: „Ich sage nicht, dass er schlecht ist, aber ich sollte in einem Blog schreiben, dass alle darin übereinstimmen, dass diese Person schlecht ist.“ Selbst wenn es stimmt, wirkt das sehr geschmacklos.

    • Ich bin unsicher, ob jemanden als „stinkenden Manager“ zu bezeichnen ein persönlicher Angriff ist. Interessant ist, dass man offenbar nicht zwischen einer Person und ihrer „Arbeit“ unterscheiden kann.
      Ich arbeite auch mit miserablen Managern, aber persönlich hege ich keinen Groll gegen sie.
    • Wenn im Rest des Textes solche Ad-hominem-Angriffe stehen, ist „keine persönliche Kritik“ nicht konsistent.
      „Das Gerüchtenetz war groß und gesund und voller saftiger Trauben, und der Saft all dieser Trauben enthielt dieselbe Botschaft: Jarred war ein stinkender Manager.“
      „Jarred schrieb schon Schrotttexte, bevor er LLMs benutzte.“
      Ein merkwürdig kindischer Text. Ich mag zwar Texte, die ohne Unternehmensfilter aussprechen, was jemand wirklich denkt, aber solche Texte zeigen eben auch, wie diese Person denkt und handelt.
      Bei guter Führung bleibt das Ergebnis auch dann professionell, wenn man den Unternehmensfilter entfernt; dieser Text offenbart etwas deutlich Schlechteres.
    • Soll das heißen, Anfänger-Energie sei unecht? Bei Nebenprojekten genieße ich Anfänger-Energie. Man scheitert und lernt.
      Wenn es sicher ist und niemand von einem abhängt, ist das völlig normal. Das ist etwas anderes als Managementarbeit.
  • Auffällig fand ich die Stelle, dass ZSF erleichtert aufatmete, als die Übernahme durch Anthropic abgeschlossen war. Selbst als die Spenden stillschweigend aufhörten, war das Konto bereit, und als sie die monatlichen Meetings weder absagten noch erschienen, war man nicht überrascht. Die Beziehung war bereits beendet.
    So etwas habe ich schon oft gesehen. Wenn ein Projekt oder eine Organisation übernommen wird, enden die „guten Dinge“, die sie getan haben, nicht lautstark; sie verschwinden einfach, weil der Sponsor sie stillschweigend zu ignorieren beginnt.
    Gut, dass sie die Zeichen gelesen und sich vorbereitet haben. Das ist eine wichtige Lektion, die man nicht selbst auf die harte Tour lernen muss, und freie/Open-Source-Projekte, die von einem oder zwei großen Spendern abhängen, sollten vorsichtig sein.
    Ich glaube, wir werden im Ökosystem der Entwickler-Tools künftig noch viel mehr davon sehen.

  • Es gibt an anderer Stelle in diesem Thread scharfe Reaktionen auf den Ton des Textes, aber dieser Text hat meine Erwartungen an Zig gedämpft.
    Das Drama ist unterhaltsam, und Andrews Aufrichtigkeit ist vielleicht bewundernswert, aber das ist nicht die Professionalität, die ein ernsthaftes Projekt braucht.
    Auch wenn es langweilig und wenig inspirierend wirkt: Für einen Tech-Stack und dessen Betrieb will ich genau diese Stabilität.
    Vielleicht war Jarred ein Nettoverlust, aber Bun war ein sehr großes Projekt, das Zig verwendete, und dass dieses Projekt geht, ist für Zig nicht so positiv, wie Andrew es darstellt.
    Er scheint Reinheit und Ideologie deutlich höher zu priorisieren als das Wachstum der Sprache. Für eine ernsthafte Programmiersprache sind Adoption und kritische Masse ebenfalls wichtige Faktoren.

    • Mir leuchtet nicht sofort ein, wie stark die Ernsthaftigkeit eines Projekts mit der Wortwahl zusammenhängt, die der Autor in seinem persönlichen Blog gewählt hat.
      Das ist ähnlich, als würde man sagen, Linux habe wegen Linus’ E-Mail-Ton kein ernsthaftes Projekt sein können.
    • Ich verstehe, dass er wütend ist. Es wirkt, als würde schon problematisiert, dass jemand Gefühle hat und Signale dieser Gefühle zeigt.
      Zumal es nicht einmal direkt an jemanden gerichtet war, sondern ein Beitrag in einem persönlichen Blog.
    • Ich sehe nicht, wie dieser Text überzeugend zeigen soll, dass Andrew Kelley die Professionalität fehlt, ein ernsthaftes Projekt wie Zig zu leiten.
      Entscheidend ist doch, was er zur Sprache beigetragen hat, oder?
    • Dieser Punkt kommt dem zentralen Gegenargument nahe, geht aber leicht daran vorbei. Es ist ein Zusammenprall traditioneller Hacker-Kultur mit VC-artigem Growth-Hacking-Denken.
      Warum müssen Adoption und kritische Masse zwingend wichtig sein? Warum sollte man keine Sprache bauen dürfen, die der eigenen Vorstellung von Reinheit und Ideologie entspricht, selbst wenn man dafür breitere Adoption aufgibt?
      Warum muss alles auf Nutzerwachstum und Bekanntheit optimiert werden?
    • In diesem Fall wurde Bun von Anthropic übernommen. Dass sie Zig verlassen haben, muss nicht unbedingt an technischen Vorteilen liegen.
      Auch wenn sie so tun, als wäre es so.
  • Dieser Text war sehr erfrischend. Die Versuchung muss groß gewesen sein, die PR-Sprache des Bun-Beitrags eleganter zu kontern, aber das hat er nicht getan.
    Er hätte auch Fakten einbauen können, die Jarred negativ aussehen lassen, und dabei die eigene Meinung vorsichtig verstecken, etwa: „Ich habe gehört, dass Leute ihn einen stinkenden Manager nennen. Nicht, dass ich das täte, andere sagen das.“ Aber ich mochte, dass er einfach ehrlich war.

    • Es ist erfrischend, dass der Autor nicht versucht, seine Persönlichkeit und Gedanken zu verbergen.
      Allerdings ist der Inhalt dieser Persönlichkeit und Gedanken ziemlich schwer zu akzeptieren.
    • Es wirkt einfach wie ein langer Ad-hominem-Angriff.
    • Zustimmung. Dieser Blogbeitrag wirkt wie ein Gleichgewicht zwischen PR-Sprech und x.com.
  • Weil der erste und größte Teil des Textes spekulativen Ad-hominem-Angriffen gewidmet ist, fällt es schwer, den Aussagen des Autors Vertrauen zu schenken.
    Das wäre eine gute Gelegenheit gewesen, die Stärken von Zig zusammenzufassen. Durch die missionarischen und inspirierenden Texte von mitchellh wollte ich zuletzt Zig lernen, aber dieser Text hat mir die Lust darauf genommen.

    • Ich glaube, du bist nicht allein mit diesem Gefühl. Kannst du bitte wörtlich zitieren, welche Stellen genau dir wie „spekulative Ad-hominem-Angriffe“ vorkamen?
      Man sieht ziemlich viel darüber, wie Andrew Jarred und dessen Arbeitsweise und Arbeitshaltung einschätzt, aber mir ist nicht klar, was daran ad hominem ist und was spekulativ oder nicht.
    • Das Problem ist, dass dieser Autor der Autor von Zig ist.
  • Persönliche Angriffe auf Jarred scheinen dem Argument, Zig zu verwenden, nicht besonders zu helfen
    Man hätte sich auf die Sprache konzentrieren sollen und keine Ausdrücke wie „stinkender Maintainer“ verwenden dürfen
    Ehrlich gesagt bekomme ich beim Lesen dieses Textes genauso das Gefühl, Andrew meiden zu wollen wie Jarred

    • Das ist keine Kritik an Jarred als Privatperson, sondern an seinem öffentlichen und unprofessionellen Verhalten
      Es ist auch etwas, das viele Menschen in der Community in den letzten Monaten beobachtet haben
      Zu sagen: „Jarred hat in seiner beruflichen Rolle viele Menschen aus unserer Community vertrieben, und wir wollen Abstand halten“, ist nicht dasselbe wie: „Jarred ist privat ein schlechter Mensch“
      Natürlich kann das in dieser Branche fast gleichbedeutend wirken, wenn man bedenkt, wie viel Privatleben VCs außerhalb der Arbeit wohl noch übrig gelassen haben, aber das ist nicht Andrews Problem
      Ich verteidige Andrews Schreibstil nicht. Wenn er zu einer breiteren neurotypischen Leserschaft spricht, hätte er seine Neurodiversität vielleicht etwas stärker kaschieren können
      Trotzdem ist es sein Projekt, seine Community kennt diese Eigenschaft bereits, und auch das ist eine bekannte Variable
      Es kann helfen, den Text noch einmal unter der Annahme zu lesen, dass Andrew es vollkommen ernst meint, statt die Nebenbedeutung hineinzulegen, „Andrew versuche Jarreds Charakter zu ermorden“
    • Andrews soziales Online-Verhalten wirkt insgesamt wie eine Abfolge von Kleinlichkeit
      Es ist nicht das erste Mal, dass ich einen Beitrag von ihm gesehen habe, der sich offen böswillig anfühlte. Das ist nicht etwas, das man beschönigend als „direkt“ bezeichnen kann
      „War Schweigen keine Option?“
  • Entgegen der Aussage, es gebe „keine persönliche Kritik an Jarred“, fühlte sich der gesamte Text wie persönliche Kritik an Jarred an

    • Ich sehe es eher als berufliche Kritik an Jarred denn als persönliche Kritik. Auch wenn der Fokus auf einer einzelnen Person liegt, halte ich es nicht für besonders privat
    • Buchstäblich drei Sätze später beleidigt er ihn wieder mit „Produktivitäts-Fantasie-Fiebertraum“
      Selbst wenn es stimmt, ist es unklug, es in dieser Form öffentlich zu machen. Wenn das Ziel war, Zig zu verteidigen, hätte man das auch auf weniger persönliche Weise tun können
    • Dieser Teil ist wohl schlecht formuliert und wirkt passiv-aggressiv, aber vermutlich hatte er Angst, dass sich die Engel des Internets empören würden, weil er unhöflich zu Jarred war
  • Diese ganze Aktion, Bun von Zig nach Rust neu zu schreiben, wirkt wie ein großer Marketing-Schachzug
    Wenn Anthropic AI wirklich so leistungsfähig ist, warum gibt man ihr dann nicht die ehrgeizigere Aufgabe, Bugs zu beheben und die bestehende Bun-Zig-Codebasis so umzugestalten, dass nicht nur die aktuellen Bugs, sondern auch ähnliche Bugs künftig gar nicht erst entstehen?

    • Der einzige Grund für das Rewrite ist, dass der Schöpfer von Zig angekündigt hat, keine AI-Beiträge anzunehmen
      Das hat Anthropics Gefühle verletzt
    • Ich frage mich, ob dieser seltsame Schritt von Anthropic ausging oder von einem überhitzten Gründer, der nach dem Deal noch mehr verkaufen wollte
      Ich kann mir vorstellen, dass Anthropic Bun auch ohne diesen Kniff hätte übernehmen wollen
    • Bemerkenswert ist, dass Bun vor dem Rewrite in Rust einen Fork zur Beschleunigung der Kompilierung pflegte und Fragenden mitteilte, dass dieser Fork wegen Zigs LLM-Verbotsrichtlinie niemals gemergt werden könne
      Einige Wochen später begann Bun mit dem Rewrite in Rust. Es wurde nicht ausdrücklich gesagt, aber ich denke, die beiden Ereignisse könnten zusammenhängen
    • Rust ist genau das Werkzeug, das sowohl Menschen als auch LLMs viele solcher Prüfungen und Werkzeuge wie RAII kostenlos bereitstellt
    • Letztlich konnte Claude diese Bugs entweder nicht beheben, oder er konnte es, aber das Bun-Team hat sich bewusst entschieden, sie nicht zu beheben
      Ich weiß nicht, welche Variante schlimmer ist