Redis Array: eine kurze Geschichte eines langen Entwicklungsprozesses

 (antirez.com)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Die Arbeit am neuen Array-Datentyp von Redis begann Anfang Januar und wurde etwa vier Monate später als PR eingereicht; im ersten Monat wurden Spezifikationen zur Notwendigkeit, zu C-Strukturen, spärlicher Darstellung, Ringpuffer und zur Semantik des Array-Cursors für ARINSERT verfasst
  • Das anfängliche Design wurde gemeinsam mit Opus verfeinert, und nach der Veröffentlichung von GPT 5.3 wurden Design und Entwicklung mit Codex vorangetrieben; im Feedback-Prozess mit der AI wurden Kompromisse und übermäßig komplex entworfene Teile fortlaufend überprüft
  • Die Implementierung wurde so geändert, dass auch das Setzen großer Indizes wie ARSET myarray 293842948324 foo ohne riesige Allokationen funktioniert; die interne Datenstruktur wechselt je nach Bedingungen zwischen Super Directory, geslictem dichtem Directory und tatsächlichen Array-Slices
  • Jeder Slice enthält standardmäßig 4096 Elemente, und mit ARSCAN und ARPOP können bestehende Arrays in einer Zeit gescannt werden, die nicht von der Gesamtgröße des Bereichs, sondern von der Anzahl der tatsächlich vorhandenen Elemente abhängt
  • Der Anwendungsfall, Markdown-Dateien in Redis-Arrays abzulegen, führte zur Implementierung von ARGREP; für die Unterstützung regulärer Ausdrücke wurde TRE gewählt, und die Anwendungsfälle sind in Redis PR #15162 zusammengefasst

Implementierung und Überprüfung

  • Ab dem zweiten Monat begann die Implementierung im Stil des automatisierten Programmierens, wobei der erzeugte Code fortlaufend überprüft wurde
  • Auch nachdem die Implementierung funktionierte, wurde der Code einschließlich sparsearray.c und t_array.c Zeile für Zeile gelesen und überprüft
  • Dank AI gab es viele Tests, doch Code, der oberflächlich funktioniert, ist nicht automatisch optimal; kleine Ineffizienzen und Designfehler wurden gefunden und behoben
  • Mehrere Module wurden manuell sowie AI-gestützt neu geschrieben, und im dritten Monat wurden auf verschiedene Weise Stresstests durchgeführt
  • Bei hochwertiger Systemprogrammierung muss der Mensch weiterhin vollständig eingebunden sein, doch mit AI gibt es ein Sicherheitsnetz für ermüdende Aufgaben wie das Hinzufügen von 32-Bit-Unterstützung und Tests sowie für das Erkennen offensichtlicher Bugs in komplexen Algorithmen
  • Die anfänglich umfangreiche Spezifikation war für die spätere Arbeit entscheidend und auch wichtig, um jede Codezeile zu überprüfen und nicht passende Teile zu korrigieren

Anwendungsfälle und reguläre Ausdrücke

  • Beim Modellieren von Anwendungsfällen wurden Markdown-Dateien in Redis-Arrays abgelegt, woraus die Erkenntnis entstand, dass Dateien gut zum Array-Datentyp passen
  • Das führte zur Implementierung von ARGREP, um eine zentrale wissensbasierte Sammlung auf Basis von Markdown-Dateien für Agenten-Workloads zu schaffen
  • Für die Unterstützung regulärer Ausdrücke wurde TRE gewählt, weil es bei der Nutzung regulärer Ausdrücke in Redis weder zeitlich noch räumlich pathologische Muster geben sollte
  • TRE ist bei nützlichem Pattern Matching wie foo|bar|zap sehr ineffizient; mit Hilfe von GPT wurde es optimiert, einige potenzielle Sicherheitsprobleme wurden behoben und die Tests erweitert
  • Die Anwendungsfälle sind in Redis PR #15162 ausführlich zusammengefasst und führten zu dem Schluss, dass Redis einen Datentyp braucht, bei dem numerische Indizes Teil der Bedeutung sind
  • Es wird um Feedback gebeten, in der Hoffnung, dass der Array-PR bald angenommen wird und die Vorteile neuer Anwendungsfälle nutzbar werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Hacker-News-Kommentare

  • Um das klarzustellen: Das ist die Arbeit des Originalautors von Redis oder eines davon
    Er ist kein „durchschnittlicher Entwickler“, und selbst mit LLMs hat es 4 Monate gedauert
    Man sollte das also nicht als Freigabestempel dafür verstehen, allen Entwicklern den vollständigen Umstieg auf Claude Code, Codex oder andere AI-Coding-Tools anzuordnen
    Vor allem gewöhnliche Startup-CEOs sollten sich das ansehen

    • Es wirkt wie ein ziemlich starkes Indiz dafür, dass erfahrene Entwickler mit geschicktem Einsatz von Coding-Agenten ihre Expertise noch weiter verstärken können
    • Der Teil „Er ist kein durchschnittlicher Entwickler, und selbst mit LLMs hat es 4 Monate gedauert“ ist im Original etwas anders
      Dort heißt es sinngemäß: „Auch vor LLMs hätte ich die Implementierung selbst wahrscheinlich in 4 Monaten geschafft. Der Unterschied ist, dass ich im gleichen Zeitraum viel mehr erledigen konnte.“
      Die Ausgangsdauer lag also ohnehin bei 4 Monaten, und dank LLMs wurde in derselben Zeit mehr Arbeit geschafft
    • Er ist nicht durchschnittlich, aber seine Arbeit ist natürlich ebenfalls nicht durchschnittlich
      Durchschnittliche Entwicklungsarbeit ist eher Klempnerarbeit und CRUD

  • So arbeite ich derzeit
    Zuerst lasse ich mit AI-Hilfe ein High-Level-Designdokument in Markdown erstellen. Danach lasse ich dasselbe Modell ohne Kontext oder ein anderes Modell Bugs, Auslassungen und Lücken kritisieren und finden. Später entdeckt es immer Dinge, die dann offensichtlich wirken
    Dann lasse ich diese Erkenntnisse zusammenfassen, füge sie bei der ersten AI ein und frage nach ihrer Einschätzung. Nach abgestimmten Änderungen werden sie übernommen, und ich setze dieses adversariale Round-Robin fort, bis kein Modell mehr sinnvolle Vorschläge macht
    Danach lasse ich die AI einen Plan erstellen, und auch dieser Plan läuft adversarial zwischen mehreren AIs. Am Ende kommt ein ziemlich robuster Plan heraus
    Anschließend geht es zu End-to-End-Testfallplänen und Ähnlichem. Je nach Größe des Systems ist man gegen Ende des ersten Tages, der ersten Woche oder des ersten Monats bereit zum Codieren
    Sobald der Code erstellt ist, füge ich ihn zusammen mit Spezifikation und Plan in andere AIs ein und lasse wieder nach Bugs, Auslassungen und Lücken suchen. Die Haupt-AI für die Implementierung wird also laufend durch andere AIs überprüft
    Natürlich muss man den Code selbst lesen. Ich habe gesehen, dass AI Feinschliff im Detail auf Release-Niveau übersieht

    • Im AI-Diskurs heißt es oft, wir hätten ein völlig neues unbeaufsichtigtes Entwicklungsparadigma eröffnet, aber faktisch ist das fast genau die Art, wie Google seit 10 Jahren Code entwickelt. Nur dass statt Menschen mit unterschiedlichem Vertrauensniveau jetzt AIs eingesetzt werden
      Das ist nicht spöttisch gemeint. Mein eigener Workflow ist im Wesentlichen derselbe, und es geht auch nicht darum, sich über Google lustig zu machen. Im Gegenteil: Es ist nichts wirklich Neues
      AI beschleunigt sowohl effektive als auch ineffektive Workflows enorm. Dadurch wird viel schneller, beinahe in Echtzeit, sichtbar, was funktioniert und was nicht
    • Mich würde interessieren, wie viel schneller oder langsamer das ist, verglichen damit, den Code direkt selbst zu schreiben
    • Diese Art von spezifikationsgetriebener Entwicklung war das zentrale Unterscheidungsmerkmal von AWS Kiro: https://kiro.dev/docs/specs/
      Es hieß auch, dass andere Agenten verwendet wurden; mich würde interessieren, ob man damit gute Erfahrungen bei Code-Reviews gemacht hat, bei denen andere Agenten weniger ausgefeilte Teile polishen. Meine Kollegen glauben stark daran, aber ich bin persönlich noch skeptisch, ob das ohne menschliche Reviewer wirklich wertvoll ist
      Dieses „eine andere AI fragen“ könnte in der angewandten Informatik vielleicht eher dem Muster These–Antithese–Synthese entsprechen: https://en.wikipedia.org/wiki/Dialectic#Criticisms

  • Selbst wenn antirez es geschrieben hat, klingt es wie ein Albtraum, bei diesem Funktionsumfang und nur einer minimalen PR-Beschreibung 22.000 Zeilen Code zu reviewen
    Man versteht dann, warum große Open-Source-Projekte wie Postgres über Mailinglisten entwickelt werden. Zwischenschritte im Design werden mit der Community diskutiert, verwandte Funktionen in getrennte Patches aufgeteilt, schrittweise reviewt und mit größerem Abstand zwischen Releases eingebracht

    • Der Code umfasst insgesamt 5.000 Zeilen inklusive Kommentare
      Sparse Arrays machen 2.000 Zeilen aus
      Die t_array-Befehle und die Implementierung der höheren Ebene 2.000 Zeilen
      AOF/RDB-Code etwa 500 Zeilen
      Der Rest sind Tests, JSON-Befehlsbeschreibungen und die TRE-Bibliothek unter deps
    • Postgres und Redis sind Projekte mit dramatisch unterschiedlichem Charakter, unterschiedlicher Geschichte, unterschiedlichen Beitragsmodellen und Entwicklerteams
      Praktisch die meisten großen Redis-Features sind Arbeiten, die der Autor allein umgesetzt hat
      Außerdem kennen die Reviewer diese Arbeit sehr gut und werden dafür auch angemessen bezahlt

  • Das ähnelt sehr stark meiner Erfahrung mit dem Einsatz aktueller Top-AI. Als Ersatz für menschliche Intelligenz und Kreativität ist sie weit entfernt, aber als Kollaborationspartner extrem nützlich

    • Ich sage oft, AI ist die Rubber-Duck-Programmierente, die ich mir immer gewünscht habe
    • Es gibt Projekte, die ich entwickle, ohne den Code fast anzusehen. Ich halte die Konzepte, Algorithmen und Ideen in der Hand, gebe Fragen und Hinweise und besitze vor allem die Produktrichtung
      Aber Redis ist noch nicht so weit. Wenn das eines Tages bei Server-Software möglich wird, ist die heutige Art der Entwicklung vorbei
      Features, Fixes und angesammelte Erfahrung bleiben weiter wertvoll, also bleiben Projekte und Repositories bestehen, aber die Rolle des Programmierers wird der Rolle sehr ähnlich werden, die Linus bisher beim Kernel innehatte
      Bei einigen Projekten wie der DeepSeek-v4-Inference-Engine wird schon jetzt so gearbeitet

  • Ich freue mich auf array/regex, und die Erfahrung, Fähigkeiten mit LLMs zu erweitern, ist ebenfalls sehr interessant. Viele Menschen probieren in mehreren Projekten stillschweigend Ähnliches aus
    Vibe Coding und die Gegenreaktion darauf beschreiben diese Arbeitsweise nicht angemessen

    • Ich würde die Art, wie Agenten hier eingesetzt wurden, überhaupt nicht als Vibe Coding bezeichnen. Die Beteiligung ist viel zu tief, und alles wird validiert, überprüft und reviewt
    • Das Problem mit „Vibe Coding“ ist, dass die Person, die den Begriff geprägt hat, ihm eine sehr konkrete Bedeutung gegeben hat. Gemeint war, Software einfach nach „Gefühl“ zu bauen, ohne den Code anzusehen
      Dann begannen Leute aber sehr schnell, den Begriff für fast jede Form von AI-unterstütztem Coding zu verwenden, wodurch die ursprüngliche Bedeutung rasch verloren ging

  • Kurz gesagt: Redis ist jetzt nicht mehr vertrauenswürdig
    Wer baut den Fork ohne LLMs?

  • Sind nicht einige der vorgestellten Use Cases auch mit ZSET möglich? Die Performance-Perspektive verstehe ich, aber so wie Arrays optional eine Sparse-Darstellung verwenden, hätte man vielleicht auch den ZSET-Speicher für dichte Werte optional optimieren können, ohne eine neue API-Oberfläche einzuführen
    Die Regex-Komponente ist interessant, aber wie hier ebenfalls angemerkt wurde, wirkt sie orthogonal zur Array-Datenstruktur. Das heißt, sie ließe sich auch bei anderen Strukturen einsetzen. Wäre das nicht eher etwas für Lua-Scripting? Falls Lua-Performance das Problem ist, könnte man vielleicht auch eine Möglichkeit finden, die OP zu abstrahieren, sodass sie sich über jeden Befehl kombinieren lässt, der einen Wertebereich zurückgibt
    Ich respektiere, dass Antirez auf diesem Gebiet ein Experte ist, aber ein Teil dieses neuen Funktionssatzes wirkt wie eine Lösung, die man bei LLM-getriebener Entwicklung oft sieht: Statt bestehende Funktionen zu verbessern, baut man neue, obwohl eine Kombination mit anderen Funktionen effektiver sein könnte, und macht das Feature-Set dadurch unnötig komplex

    • Leider nein. Sortierte Mengen liegen fast am entgegengesetzten Ende des Spektrums. Semantisch sind sie elegant, aber die Kombination aus Skip List und Array ist sehr verschwenderisch
      Außerdem können Bereichsabfragen und Ringpuffer nicht so effizient und kompakt arbeiten, wie nötig, wenn die interne Darstellung kein Array ist
      Theoretisch kann man mit allem alles machen, aber man muss trennen, was jede API leisten soll, damit man aus den Use Cases die bestmögliche interne Implementierung ableiten kann

  • Ich würde antirez gern fragen, ob er mit dem finalen Code praktisch One-Shot-Generierung ausprobiert hat. Ich frage mich, ob man mit GEPA dorthin kommen könnte und ob sich aus den Lenkungs- oder Prompting-Methoden, mit denen man das gewünschte Ergebnis herauszieht, etwas lernen ließe
    Oder ob das Fazit eher sein müsste, dass die Modellanbieter ihre Trainingsdaten besser aufräumen sollten

  • Es wirkt so, als wolle Salvatore den Begriff Automatic Programming/Coding populär machen. (https://antirez.com/news/159)

    • https://en.wikipedia.org/wiki/Automatic_programming ist ein in der Informatik anerkannter Begriff für alle Mechanismen, mit denen Code automatisch aus Beschreibungen auf höherer Abstraktionsebene erzeugt wird
      Natürlich sind LLMs insofern sehr ungewöhnlich, als sie nicht deterministisch sind und einen überraschend breiten Anwendungsbereich haben, aber das bedeutet nicht, dass der Begriff hier nicht passt
    • Ich verwende selbst immer seltener Worte, um dieselbe Sache zu beschreiben. Mit der Zeit machen wir „diese“ Arbeit einfach immer häufiger
      Vielleicht würde es aber helfen, den Begriff auf auto-code zu verkürzen

  • Es ist immer interessant zu sehen, wie sehr erfahrene Entwickler heute mit AI interagieren
    @antirez: Es wirkt etwas seltsam, dass in einer späten Projektphase noch die scheinbar separate Regex-Funktionalität eingeführt wurde. Kannst du die Überlegung dahinter etwas näher erläutern?

    • Als mir klar wurde, dass Arrays sehr gut zu Textdateien passen, stieß ich bei vielen denkbaren Use Cases darauf, dass man am Ende doch grep auf Dateien braucht
      Also fragte ich mich, was das AROP-Äquivalent für Dateien wäre, und die Antwort war ARGREP
      Danach habe ich sowohl schnelle exakte Treffer als auch Regex-Matches eingebaut, damit man je nach Use Case das optimale Werkzeug wählen kann
      Dabei stellte sich heraus, dass Regex bei mehreren mit OR verknüpften Strings schneller sein kann, wenn sie gut optimiert ist, und ich habe TRE deshalb etwas spezialisiert