Das Programm „Build It Yourself“ selbst erstellen

• Ein anderer Blick auf Abhängigkeiten

  • Es wird eine neue Perspektive auf Abhängigkeiten vorgeschlagen. Es ist nötig, den übermäßigen Einsatz von Abhängigkeiten zu reduzieren und dazu überzugehen, Code selbst zu schreiben.

• Das Abhängigkeitsproblem

  • „Dependency Consumption“ ist die endlose Wiederholung von Updates, Patches, Audits und transitiven Abhängigkeiten, die Entwickler für ihre Produktivität installieren.
  • JavaScript und Rust sind besonders anfällig für Abhängigkeitsprobleme. Beispielsweise umfasst ein neues Tokio-Projekt 28 Crates, ein Rocket-Projekt wächst auf 172 an.

• Das Terminalgrößenproblem

  • Das Crate terminal_size bietet eine einfache Funktion zum Messen der Terminalgröße, benötigt jedoch mehrere zusätzliche Crates.
  • Dadurch entsteht eine Situation, in der Tausende anderer Funktionen kompiliert werden müssen.

• Die Notwendigkeit von Abhängigkeiten

  • Da auf Bibliotheken zur Plattformabstraktion aufgebaut wird, sind Updates nötig, um Codeduplizierung zu vermeiden und Kompilierzeiten zu verkürzen.
  • Häufig sind sie eine Hauptursache für Sicherheitsprobleme.

• Das Ziel von Code

  • Code sollte so geschrieben werden, dass er keine Updates benötigt. Im Rust-Ökosystem wird stabiler Code benachteiligt.

• Vorteile von selbst geschriebenem Code

  • Wenn man Code selbst schreibt, braucht man keine neuen Crates, und der Wartungsaufwand sinkt.
  • Mit Tools wie ChatGPT lassen sich Implementierungen ohne Abhängigkeiten schnell schreiben.

• Open Source und Unternehmenskultur

  • Die Code-Review-Kultur in Unternehmen beeinflusst Open-Source-Software.
  • Die Nutzung neuer Bibliotheken wird positiv gesehen.

• Warum eine neue Perspektive nötig ist

  • Ingenieure, die kleine Funktionen selbst schreiben, sollten gelobt werden.
  • Gegenüber großen Crate-Graphen sollte man misstrauisch sein.

• Wichtige Bibliotheken

  • Es gibt auch wichtige Bibliotheken, die komplexe Probleme lösen, zum Beispiel Grafikbibliotheken oder Protokollimplementierungen.

• Warum Selbstbauen wichtig ist

  • Wenn es sinnvoll ist, sollte man es feiern, selbst etwas zu bauen.
  • Bibliotheksautoren, die Open-Source-Bibliotheken mit wenigen oder keinen Abhängigkeiten erstellen, sollten Anerkennung erhalten.

• Fazit

  • Wir sollten dazu übergehen, Abhängigkeiten zu reduzieren und Code selbst zu schreiben.
  • minijinja ist ein Beispiel für minimale Abhängigkeiten und hängt nur von serde ab.

[GN⁺]

Hacker-News-Kommentare

• Ich mag die Sprache Rust, aber ich hasse die Abhängigkeitsprobleme von Rust. Das Abhängigkeitsmanagement von C++ ist besser. In C++ kann man Abhängigkeiten selbst kontrollieren, aber in Rust entstehen zu viele Abhängigkeiten, sodass man am Ende aufgibt. Auch aus Sicherheitssicht ist nicht klar, was ich eigentlich ausliefere. Rust hat keine ABI-Kompatibilität, und eine Kultur gemeinsamer Bibliotheken gibt es kaum. Das zerstört das Distributionsmodell von OS-Paketen.

• Die Terminal-API ist nicht stabil. Das TIOCGWINSZ-ioctl ist nicht standardisiert, und dass die Funktion tcgetwinsize() zu POSIX hinzugefügt wurde, geschah erst 2024. Unter Windows ist es noch komplizierter.

• Ich habe eine Web-App aus dem Jahr 2006 wiederbelebt. Um neue CI/CD-Techniken zu lernen, habe ich den Deployment-Prozess der App übermäßig ausgefeilt gestaltet. Verwendet wurden PHP und MySQL, und den Großteil des Codes habe ich selbst geschrieben. Es dauerte nur eine Stunde, die 19 Jahre alte App wiederzubeleben. Dagegen ist die Spring-Boot-App, die wir derzeit bei der Arbeit nutzen, wegen Abhängigkeitsproblemen schwer zu aktualisieren.

• NodeJS hatte großen Einfluss auf meine Karriere, aber NPM verursacht viele Probleme. Wenn man versucht, eine neue Abhängigkeit hinzuzufügen, gerät sie mit anderen Abhängigkeiten in Konflikt. Bei Expo gibt es etwa das Problem, dass ein Standard-React-Native-Projekt unter Android nicht gebaut werden kann. Dass selbst große Projekte nicht funktionierende Templates ausliefern können, gibt mir irgendwie Zuversicht.

• Das Rust-Ökosystem hat im Vergleich zu Go viele Abhängigkeiten. In Go werden Interfaces implizit erfüllt, sodass keine zusätzlichen Abhängigkeiten nötig sind.

• Die Abstraktion von Bibliotheken hat versteckte Kosten. Wenn ein Paket sein Design ändert, entsteht Instabilität. Das Einfache überlebt am längsten. Ich sehe ähnliche Probleme nicht nur bei Rust, sondern auch in anderen Sprachen.

• Mit ChatGPT oder Cursor geht es schneller, eine Implementierung ohne Abhängigkeiten zügig zu erstellen. Viele Abhängigkeiten von SaaS-/3rd-Party-Services betreffen Probleme, die bereits gelöst sind.

• Flask und Bottle hatten ähnliche Funktionen, aber Flask wurde populärer. Bottle bestand aus einer einzigen Datei und hatte keine Abhängigkeiten, sodass man es leicht in ein Projekt kopieren konnte. Es folgte jedoch nicht den modernen Python-Praktiken und wirkte dadurch veraltet.

• Man braucht fähige Engineers, die selbst Lösungen entwickeln können. Man kann leicht bessere Lösungen bauen als bestehende Bibliotheken. In einem Projekt habe ich einen Parser für Markdown-Varianten geschrieben, aber meine Teammitglieder wollten ihn aus Wartungsgründen nicht verwenden.

• Es ist problematisch, Hunderte von Funktionen zu kompilieren, obwohl man nur eine einzige Funktion verwendet. In einem Projekt zur Aktualisierung von 3rd-Party-Abhängigkeiten wurde nur eine Methode aus einer Mathematikbibliothek genutzt. Ich habe dem Engineer empfohlen, sich an der entsprechenden Wikipedia-Seite zu orientieren und die Methode selbst zu schreiben. Das Problem ist nicht die Nutzung von 3rd-Party-Abhängigkeiten an sich, sondern dass ein Konzept fehlt, mit dem man nur kleine Teile aus einer Bibliothek übernehmen kann. Ein "Mikro-Framework" könnte die Lösung sein.