Wenn KI den Code schreibt – warum dann Python?

 (medium.com/@NMitchem)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Mit KI-gestützter Entwicklung verlagern sich die Kriterien bei der Sprachwahl von der Schreibgeschwindigkeit des Menschen hin zur Korrekturfähigkeit der KI und zur Laufzeit-Performance
  • 2026 überschritten Claude Opus 4.7, GPT-5.5, Gemini 3.1 und DeepSeek V4 bei SWE-bench Verified 80 %
  • Rust hilft der KI durch die Compiler-Feedback-Schleife bei der Selbstkorrektur, und auch Go und Swift sind mit ihrer schnellen Typprüfung für Agenten vorteilhaft
  • Große Umstellungen laufen bereits, etwa das Go-Porting des TypeScript-Compilers, ein Rust-basierter C-Compiler, Rue oder das Porting der Ladybird-JavaScript-Engine
  • Auch die Python- und JavaScript-Ökosysteme hängen zunehmend von Rust-Tools und Wrappern ab, doch Ausnahmen wie Prisma, PyTorch und kleinere Sprachen bleiben bestehen

KI-gestützte Entwicklung verändert die Kriterien der Sprachwahl

  • Die Standardwahl für neue Projekte war lange Zeit Python oder TypeScript
    • weil die Ökosysteme groß waren, der Talentpool breit und sich Demos schnell bauen ließen
    • Rust, Go und C++ konnten zwar 10- bis 100-fache Performance liefern, doch Lernaufwand, kleinerer Arbeitsmarkt und kompliziertere Build-Systeme machten sie teuer
    • deshalb brachte man zuerst die Python-Version heraus und sagte: „Die Performance verbessern wir später“ – was in der Praxis oft nie geschah
  • Seit KI auch schwierige Sprachen bewältigt, gerät dieser Tauschhandel ins Wanken
    • Bei der Sprachwahl zählt nun stärker, ob KI gut schreiben und korrigieren kann, statt nur, ob Menschen schnell schreiben können, zusammen mit der Laufzeit-Performance

Schwierige Sprachen werden für KI zuerst leicht

  • Vor zwei Jahren lag GPT-4 bei Rust-Funktionen noch auf dem Niveau, nicht existierende crate-Namen zu erfinden
  • Im April 2026 überschritten Claude Opus 4.7, GPT-5.5, Gemini 3.1 und DeepSeek V4 im Abstand von nur wenigen Wochen die 80-%-Marke bei SWE-bench Verified
  • Forschungslabore optimieren inzwischen explizit für Systemarbeit
    • Concurrency-Bugs
    • Race Conditions
    • Architekturfehler, die bereits in der Planungsphase sichtbar werden
  • CtrlAltDwayne sieht Rusts Stärke im Jahr 2026 weniger in Speicher­sicherheit oder Performance als in der Compiler-Feedback-Schleife
    • KI schreibt Rust besser als C++
    • Die Fehlermeldungen des Rust-Compilers werden zu Signalen, die dem Modell bei der Selbstkorrektur in Echtzeit helfen
    • Rust wirkt wie eine Sprache, die zehn Jahre zu früh „zufällig“ für KI-gestützte Entwicklung entworfen wurde
  • Dieselbe Logik gilt – in unterschiedlichem Ausmaß – auch für Go und Swift
    • Starke Typsysteme und schnelle Compile-/Prüfschleifen geben Agenten enge Iterationszyklen
    • Systemsprachen, die für Menschen schwer waren, können für Agenten gerade deshalb leichter sein

Konkrete Beispiele aus der Praxis

  • Microsoft portiert den TypeScript-Compiler nach Go

    • Mit TypeScript 7.0 beta hat Microsoft eine zehn Jahre alte TypeScript-Codebasis nach Go portiert
    • TypeScript 7.0 beta ist ungefähr 10-mal schneller als 6.0
    • Laut Anders Hejlsbergs Einschätzung liefert Go den Großteil der Performance-Vorteile zu einem Bruchteil der Engineering-Kosten
    • Eines der größten JS/TS-Teams der Welt wählt für sein zentrales Tool also bewusst eine schwierigere, schnellere Sprache – ein Zeichen dafür, dass sich die Kosten-Nutzen-Rechnung verschoben hat

  • Ein Rust-basierter C-Compiler, gebaut mit 16 Claude-Agenten

    • Der Anthropic-Forscher Nicholas Carlini koordinierte 16 Claude-Agenten parallel, um einen produktiven C-Compiler in Rust zu schreiben
    • Der Umfang liegt bei 100.000 Zeilen, und Linux 6.9 bootet darauf auf x86, ARM und RISC-V
    • QEMU, FFmpeg, SQLite, PostgreSQL und Redis werden kompiliert, und sogar Doom läuft darauf
    • Die Gesamtkosten lagen über fast 2.000 Claude-Code-Sessions hinweg bei unter 20.000 US-Dollar
    • Ein in Rust geschriebener C-Compiler war früher Stoff für eine Graduiertenarbeit – heute ist das nicht mehr nur eine Ausnahmeleistung

  • Steve Klabniks Rue

    • Steve Klabnik, Mitautor von The Rust Programming Language und seit 13 Jahren Rust-Veteran, entwickelte zusammen mit Claude in zwei Wochen eine neue Systemsprache namens Rue
    • Das Ergebnis waren ungefähr 70.000 Zeilen Rust
    • Er sagte, dass diese zwei Wochen weiter führten als frühere Versuche, die ein bis zwei Monate gedauert hatten

  • Porting der Ladybird-JavaScript-Engine nach Rust

    • Andreas Kling, Gründer des Ladybird-Browsers und C++-Ingenieur, gab Claude Code und Codex Hunderte kleiner Prompts und portierte so Ladybirds JavaScript-Engine in zwei Wochen von C++ nach Rust
    • Das Ergebnis umfasste ungefähr 25.000 Zeilen Rust und erreichte Byte-für-Byte-Gleichheit mit dem C++-Original
    • Über mehr als 65.000 kombinierte test262- und Ladybird-Tests hinweg gab es keine Regressionen
    • Von Hand hätte dieselbe Arbeit nach seiner Aussage mehrere Monate gedauert

Die Logik des „Ökosystems“ wird schwächer

  • Das stärkste Argument für Python und JavaScript war weniger die Sprache selbst als das Ökosystem
    • FastAPI, Django, PyTorch, React, Next.js und die 4 Millionen npm-Pakete lieferten die Grundlage
    • Teams konnten Funktionen in wenigen Tagen veröffentlichen, weil das Ökosystem bereits 90 % des Problems gelöst hatte
  • Dieser Vorteil war in den vergangenen zehn Jahren entscheidend, verliert aber in den letzten zwei Jahren an Stärke
  • Auch innerhalb des Python-Ökosystems wächst die Abhängigkeit von Rust-basierten Komponenten
    • Der gesamte Validierungskern von pydantic ist eine Rust-Bibliothek
    • Polars, eine Alternative zu pandas, ist in Rust geschrieben
    • Auch Hugging Face tokenizers und orjson sind in Rust geschrieben
    • Laut der JetBrains 2025 Python survey stieg der Anteil von Rust in Python-Binary-Extensions innerhalb eines Jahres von 27 % auf 33 %
  • Auch die Infrastruktur der Entwicklertools bewegt sich in diese Richtung
    • Astral, 2022 von Charlie Marsh gegründet, veröffentlichte mit Rust geschriebene Tools wie ruff, uv und ty; deren monatliche Downloads wuchsen von null auf Hunderte Millionen
    • Am 19. März 2026 übernahm OpenAI Astral und geht davon aus, dass uv Codex pro Woche rund 1 Million Minuten Rechenzeit spart
    • Zehn Wochen zuvor hatte Anthropic bereits Bun übernommen
    • Bun kommt auf 7 Millionen monatliche Downloads und 89.000 GitHub-Stars und wird als „essenzielle Infrastruktur für KI-getriebenes Software Engineering“ bezeichnet
    • Evan Yous VoidZero veröffentlichte Rolldown-Vite
    • Dieser Rust-Bundler reduzierte einen 2,5-Minuten-Build bei GitLab auf 40 Sekunden und senkte den Speicherverbrauch auf ein Hundertstel
  • Lee Robinson, VP Product bei Vercel, sagt, man habe „den Höhepunkt der Optimierung in JS erreicht“
  • Pakete aus Python und JavaScript werden zunehmend zu Wrappern um Code, der in Sprachen geschrieben ist, die früher als zu schwierig für direkte Produktivnutzung galten
    • Wenn man heute direkt in solchen Sprachen ausliefern kann, wirken Wrapper zunehmend wie Overhead

Wenn Porting einfacher wird als Patching

  • Der positive Kreislauf klassischer Open-Source-Ökosysteme war patch-zentriert
    • Man wählte Python, weil es leicht war
    • entdeckte einen Bug in einer Abhängigkeit
    • reparierte ihn und brachte den Fix upstream ein
    • und das Ökosystem wurde gesünder
  • Agenten verschieben die Einheit des Beitrags von Patches hin zu Portings
  • Flask-Gründer Armin Ronacher nutzte im Januar Agenten, um seine Rust-Bibliothek MiniJinja nach Go zu portieren
    • Die Gesamtlaufzeit betrug 10 Stunden
    • davon 3 Stunden unter Aufsicht und 7 Stunden unbeaufsichtigt
    • die tatsächliche menschliche Arbeitszeit lag bei 45 Minuten
    • die API-Kosten betrugen 60 US-Dollar
  • Wenn ein Porting zwischen Sprachen zu einer 45-Minuten-Aufgabe wird, verliert die Logik, Änderungen in die Bibliothek eines anderen einzubringen, an Kraft
    • Nicht mehr „Wenn man patchen kann, warum nicht forken?“, sondern „Wenn man forken kann, warum patchen?“
  • Armin Ronacher meint, dass Wert sich vom Code hin zu Tests und Dokumentation verlagert
    • Eine gute Testsuite kann wertvoller sein als der Code selbst
  • Der Kreislauf, der PyPI und npm groß gemacht hat, funktioniert noch – aber ob er 2028 noch genauso funktioniert, ist unklar

Ausnahmen bleiben bestehen

  • Nicht jede Entwicklung verläuft nur in eine Richtung
  • In manchen Fällen ist die bisherige Wahl weiterhin die richtige
    • Prisma entfernte seine Rust Query Engine und wechselte zu einem TypeScript/WASM-Kern
    • Die Bundle-Größe sank um 85 %, und Abfragen wurden um bis zu 3,4-mal schneller
    • Native Rust-Binaries sind in Serverless-Runtimes nachteilig
  • PyTorch hält weiterhin rund 85 % der Deep-Learning-Forschung
    • Da Modellgewichte kaum davon abhängen, in welcher Sprache sie eingebettet werden, dürfte sich diese Position nicht leicht verschieben
  • KI beherrscht nicht jede Systemsprache gleich gut
    • Bei kleineren Sprachen wie Zig, Haskell oder Gleam ist die Qualität KI-generierten Codes derzeit nicht auf dem Niveau von Rust oder Go
    • Die Trainingsdaten bestimmen, wie weit Modelle helfen können
    • Rust und Go profitieren davon, dass sie auf GitHub reichlich vertreten sind
    • Zig, Haskell und Gleam liegen auf dieser Kurve noch auf der ungünstigeren Seite

Warum dieser Wandel anhalten könnte

  • Die traditionelle Verteidigung von Python und TypeScript war im Kern eine Verteidigung der Developer Experience
    • Man wählte sie, weil sie die Reibung zwischen menschlicher Idee und ausgeliefertem Produkt minimierten
    • Rust war keine langsame Sprache zur Laufzeit, sondern eine langsame Sprache, wenn um 2 Uhr nachts noch ein Release raus musste
  • Nun übernehmen Agenten zunehmend die schwierigen Teile
    • Die Rolle des Menschen verschiebt sich vom Code schreiben hin zu Systeme entwerfen und Ergebnisse prüfen
    • In diesem Fluss wird die syntaktische Bequemlichkeit von Python mit jeder Verzweigung weniger wichtig
    • Die Laufzeitvorteile schwierigerer Sprachen akkumulieren sich dagegen an jedem Tag, an dem der Service in Produktion läuft
  • In seinem Februarbeitrag A Language For Agents argumentiert Armin Ronacher, dass mit den stark sinkenden Coding-Kosten die Breite des Ökosystems an Bedeutung verliert
  • Die Sprachwahl der letzten 20 Jahre wurde durch die Annahme geprägt: „Menschen schreiben den Code, und Menschen sind in Low-Level-Sprachen langsamer“
    • Diese Einschränkung beginnt zu verschwinden
  • In der Stack-Overflow-Umfrage 2025 war Rust das zehnte Jahr in Folge die am meisten bewunderte Sprache und erreichte 72 %
    • Gleam lag bei 70 %
    • Elixir bei 66 %
    • Zig bei 64 %
    • Die Präferenz war also bereits da; nun holt das Tooling dazu auf

Der nächste Schritt: Sprachen, die für Agenten leicht sind

  • Karpathy sagte im Februar, dass LLMs die gesamte Landschaft der Software-Constraints verändern
    • Er sieht erste Anzeichen davon in der Welle von Portings von C nach Rust
    • Selbst Rust, so ergänzt er, sei als Zielsprache für LLMs noch nicht wirklich optimal
  • Die heutigen Gewinner sind womöglich nur der Startpunkt; die endgültige Form könnte noch weiter entfernt liegen
  • @RealRichomie schrieb am 24. April, dass die Zukunft der Programmierung nicht zu der Sprache führen werde, die für Menschen am leichtesten ist, sondern zu der, die für Agenten am leichtesten ist
    • Ingenieure veröffentlichten eine Mac-App, ohne Rust oder Tauri vorher überhaupt zu kennen
    • Das Ergebnis war gegenüber einer Electron-Version etwa zehnmal kleiner und bot bessere Laufzeit-Performance
    • Menschen mussten Rust nicht lernen, um dieses Ergebnis zu erreichen
  • Das nächste Projekt muss Python nicht mehr zwingend als Standard setzen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Hacker-News-Kommentare

  • Wenn man der Behauptung zustimmt, dass LLM-Coding-Tools wie nichtdeterministische Compiler zu sehen sind, ergibt es durchaus Sinn, möglichst performante Sprachen zu wählen
    Natürlich gibt es viele Ausnahmen wie Bibliotheken oder sprachspezifische native Vorteile, aber nachdem ich etwa den letzten Monat mit C++ gearbeitet habe, war das Einzige, was durch die Sprachwahl langsamer wurde, die Kompilierzeit

  • Ich war überrascht, dass ich in den frühen Kommentaren nichts über Trainingsdaten gesehen habe. Python-Code ist in den Trainingsdaten extrem häufig vertreten
    Mit KI kann man zwar auch Brainfuck schreiben, aber ich glaube nicht, dass dabei dieselben Ergebnisse herauskommen wie mit Python
    Die Anschlussfrage ist also: Wenn es jetzt KI gibt, warum sollte man sich dann überhaupt um die Sprache kümmern, bevor es nötig wird?

    • Ich bekam Lust, nach 5 Jahren wieder Perl zu benutzen, und brauchte eine sehr einfache Möglichkeit, einen Proxy hochzufahren, den ich sonst in Go gebaut hätte, und mehrere Integrationstests zu schreiben
      Das meiste davon habe ich mit Claude Code geschrieben, und Claude konnte wirklich gut mit Perl umgehen. Ich sagte, es solle CPAN nicht anfassen und nur die Perl-Standardbibliothek verwenden, und HTTP-Client, TLS und JSON waren alle bereits eingebaut. So konnte ich Dinge, die ich sonst mit Shell-Skripten umgesetzt hätte, auf eine sehr robuste und einfache Weise ersetzen
      Weil sich Perl nicht stark verändert hat und es viele Trainingsdaten gibt, scheint Claude Perl ziemlich gut einsetzen zu können, in Situationen, in denen man sonst an Shell-Skripte denken würde
    • Überraschenderweise können LLMs bei agentischen Coding-Aufgaben mit Python-Reasoning deutlich schlechter umgehen als mit anderen gängigen Programmiersprachen
      Die Daten dazu sind hier: https://gertlabs.com/rankings?mode=agentic_coding
    • Nimm einfach Go. LLMs haben viel Go gesehen, schreiben es gut, es kompiliert fast sofort, und man bekommt alle Vorteile einer typisierten kompilierten Sprache
      Ich habe mit KI eine große Python-Codebasis erstellt, und die LLMs haben ständig Argumente oder Dictionary-Formate falsch geraten. Unit-Tests oder Werkzeuge wie pydantic helfen zwar, aber es ist besser, solche Laufzeitfehler von vornherein zu vermeiden
    • Allein mit Trainingsdaten ist die Frage nicht beantwortet. LLMs sind wirklich gut darin, in andere Programmiersprachen zu übersetzen. Wenn man bedenkt, dass sie aus Textübersetzungssystemen hervorgegangen sind, ist das naheliegend
      Ich habe auch bei Sprachen mit relativ wenig öffentlichem Code hervorragende Ergebnisse gesehen. Das größere Hindernis ist, dass LLMs dazu neigen, die gängigen Idiome der Zielsprache zu kopieren. Bei „enterprise-artigen“ Sprachen wie Java oder C# kann die Menge nutzlosen Boilerplate-Codes dadurch sofort explodieren. Dann steigt das Risiko, dass das Ergebnis die nutzbare Kontextfenstergröße überschreitet und die Qualität leidet
    • Wenn man KI in einer offenen Schleife Code erzeugen lässt, können Trainingsdaten wichtig sein. Bei Python ist die Wahrscheinlichkeit hoch, dass jemand bereits Code geschrieben hat, der dem Gewünschten ähnelt
      Wenn ein Agent aber Code erzeugt, einen Kompilierversuch startet, die detaillierten Fehlermeldungen sieht und den Code daraufhin verfeinert, kommt dabei ein qualitativ besseres Ergebnis heraus. rustc-Diagnosen sind sehr gut, und auch wenn es viel mehr Python oder JavaScript/TypeScript gibt, steht inzwischen genug Rust-Code online

  • Warum Python? Weil ich es seit über 10 Jahren benutze, weiß, wie ich darin debugge, und innerhalb von 10 Sekunden am Geruch erkennen kann, ob ein Agent etwas baut, das in einem großen Desaster enden könnte
    Bei anderen Sprachen ist das nicht so, und ich müsste viel neu lernen. Selbst wenn KI schnell Code ausspuckt, bevorzuge ich Python, weil ich dabei das Gefühl habe, noch ein gewisses Maß an Kontrolle zu behalten. Mit Go oder Rust hätte es sich weniger wie KI-gestützte Programmierung und mehr wie pures YOLO-„Vibe Coding“ für das gesamte Produkt angefühlt

    • Ich habe erst im Agenten-Zeitalter angefangen, Rust zu verwenden, und meine Erfahrung aus anderen Sprachen hat mir trotzdem weitergeholfen, Code Smells und schlechte Architektur zu erkennen
      Beim Thema Speichersicherheit musste ich lernen, was „richtig“ ist, aber ansonsten lief es gut
      Die Syntax tritt immer mehr in den Hintergrund, und man konzentriert sich auf höhere Ebenen und erkundet neue Wege. Wenn man es einmal ausprobiert, könnte man angenehm überrascht sein, wie viel Erfahrung tatsächlich übertragbar ist
    • Bei mir war es ähnlich. Bei von KI erzeugtem Python-Code kann ich nach ein paar Zeilen riechen, ob das Unsinn ist, deshalb nutze ich für die meisten Projekte weiterhin Python

  • Wenn KI den Text schreibt, warum dann überhaupt noch das Gehirn benutzen?

    • Das ist nichts zum Auslachen. Die Modelle sind viel besser als letzten Monat, und die Token-Kosten sind gesunken. LLMs sind wie Compiler fürs Gehirn
      /s

  • Warum damit aufhören, KI Rust schreiben zu lassen? Wenn ohnehin alles Vibe Coding ist und niemand mehr Code Reviews macht, sollte man LLMs eine ultrakompakte, ultradichte Sprache entwerfen lassen, die nur auf minimalen Token-Verbrauch und Geschwindigkeit optimiert ist
    Am Ende dieses Kommentars steht ein nur teilweise ironisch gemeintes /s

    • Warum beim Code aufhören? Wir sollten alle maßgeschneiderte ASIC-Chips entwerfen, und wenn wir keine Chipfab haben, dann wenigstens ein FPGA

  • Etwas off topic, aber ich verstehe wirklich nicht, warum Leute immer noch auf Medium veröffentlichen
    Das Leseerlebnis ist furchtbar. Ein Vollbild-Popup hat mir buchstäblich den Satz verdeckt, den ich gerade gelesen habe, sodass ich den Artikel nicht einmal zu Ende lesen konnte
    Gibt es irgendeinen Anreiz, den ich nicht sehe?

    • Nichts, was man im Browser liest, kann letztlich allen dieselbe großartige und eindeutig beste Leseerfahrung bieten. Das moderne Webmodell steht dem grundsätzlich entgegen
      Eine einfache HTML-Seite ohne CSS ist fast eine perfekte Leseerfahrung. Das Problem ist, dass fast niemand so ausliefert. Das Web ist zu einer Publishing-Plattform geworden, auf der Autoren um Aufmerksamkeit konkurrieren. Ein Plain-Text-Protokoll unter Kontrolle der Nutzer kommt „der besten Leseerfahrung für alle“ näher. Das Web hätte das auch sein können, ist es aber meistens nicht
      Ich habe aufgehört, lange Texte im Browser lesen zu wollen. Wenn ich den relevanten Plain Text oder sogar strukturierten Text leicht extrahieren und im Editor lesen kann, warum sollte ich dann im Browser lesen? Dort habe ich Kontrolle über Schriftarten, Farben, Navigation und so weiter. Der Browser ist ein Transportmittel, keine Leseumgebung. Ihn so zu behandeln ist Gewohnheit, keine Notwendigkeit
      Schon seit langer Zeit schreibe ich nichts mit mehr als drei Wörtern außerhalb eines Editors. Rechtschreibprüfung, Thesaurus, Etymologie-Nachschlagen, Übersetzung, Zugriff auf all meine Notizen und LLM-Anbindung: Alles, was ich brauche, ist dort schon vorhanden. Wenn man das einmal ausprobiert, fühlt es sich enorm befreiend an. Dann kann man auch damit aufhören, lange Texte im Browser zu lesen

    • Medium hat ziemlich ernsthaft versucht, Autorinnen und Autoren zu bezahlen. Es ist ein anderes Modell als Substack, aber das ist der Grund
      Ich sehe es ähnlich wie Paywalls bei Zeitungen. Mir gefällt das nicht, aber ich verstehe, warum es das gibt

    • Die plausibelste Vermutung ist Trägheit. Manche Menschen haben eine sehr starke Markentreue und orientieren sich daran, was andere tun und wie sie es tun
      Eigentlich ist es egal, wo etwas veröffentlicht wurde, solange man die URL bekommt, aber nicht alle verhalten sich so

    • Es wirkt wie die neueste Evolution einer autorenfreundlichen Blogging-Plattform. Im Vergleich zu WordPress lässt es sich leichter in Newsletter-Form bündeln und mit einer Bezahlstufe monetarisieren

    • Versuch mal Scribe, ein alternatives Frontend für Medium, das ist viel besser:
      https://scribe.rawbit.ninja/@NMitchem/if-ai-writes-your-code...

      https://sr.ht/~edwardloveall/Scribe/
      https://libredirect.github.io/

  • Python hat ein viel reiferes Ökosystem als Rust, besonders im Bereich KI/Machine Learning
    Ich bin auf ein Rust-Crate gestoßen, das angeblich einen bestimmten Machine-Learning-Algorithmus implementiert, aber nicht korrekt funktionierte. Mit Claude konnte ich trotzdem eine Ersatzimplementierung schreiben
    Ich halte es für eine gute Idee, mit KI Sprachen wie C# oder Rust häufiger als Python zu wählen, weil dort Korrektheit auf Ebene des Typsystems erzwungen wird. Für manche Aufgaben ist Python aber eindeutig das richtige Werkzeug

    • Ich wähle fast immer Rust. Kürzlich habe ich ein Plugin für etwas gebaut, das in Go geschrieben war
      Ich hätte auch Rust nehmen können, aber wenn das Ergebnis gut wird, haben andere mehr davon, mit einer einzigen Toolchain zu arbeiten, also fühlte sich Go richtig an
      Der Hauptgrund ist, dass es bei Bedarf lesbar sein muss. Außerdem gibt es in jedem Ziel-Ökosystem eine erwartete Sprache. Dass manche Data-Science-Communities R, MatLab, Julia, Python oder Mojo wählen, hängt nicht nur davon ab, was technisch überlegen ist, sondern auch davon, was die Kolleginnen und Kollegen verwenden
    • Ich denke, der einzige Anwendungsfall ist das Wrappen von Low-Level-C++-Bibliotheken wie Machine-Learning-Libraries. Solche Dinge nachzubauen ist wirklich schwer
    • Es gibt mehrere Gründe, warum die Erzwingung durch ein Typsystem mit KI gut ist
      Meine Vermutung ist, dass typisierte Sprachen oft schnellere und bessere Language Server haben, sodass Code mit Tooling effizienter geändert werden kann
      Und wenn Menschen selbst eingreifen müssen, um Code zu untersuchen oder zu ändern, erleichtern starke Typen die Orientierung in Spaghetti-Code erheblich
    • Zum Library-Support für KI/Machine Learning lässt sich definitiv etwas sagen. Trotzdem lande ich bei Backend-Arbeit inzwischen oft bei Rust/TypeScript. Und das, obwohl ich Django wirklich sehr mag
    • Wenn man das Python-Ökosystem verlässt und KI Abhängigkeiten verwalten oder polyfillen lassen will, dann wäre ich eher bei OCaml/F# als bei Rust
      Dann hat man die Vorteile von Garbage Collection und starken Typen

  • Der Grund ist im Moment genau derselbe wie beim von Menschen geschriebenen Python: Es gibt mehr Leute, die Python kennen, als etwa Zig, daher können Menschen den Code leichter lesen und ändern
    Ich verstehe den Punkt des Artikels, aber ich glaube nicht, dass wir schon an diesem Punkt sind

    • Eine Welt, in der Automatisierung in Sprachen schreibt, die Menschen nicht verstehen, erinnert mich an eine völlig dunkle chinesische automatisierte Fabrik. Menschen sind darin verloren und verwirrt, aber die Roboter fühlen sich dort zu Hause

  • „Eine App, die in einer Sprache veröffentlicht wurde, die niemand im Team kennt“ klingt großartig. In nicht allzu ferner Zukunft werden wir auf so etwas zurückblicken

    • So etwas gab es auch schon vor KI. Vor 10 Jahren hat jemand ein kritisches Werkzeug in einer zufälligen Sprache geschrieben, und alle anderen mussten es warten. Irgendwie hat es trotzdem funktioniert
    • Vielleicht das einzige Ding auf der Welt, das noch beängstigender sein könnte als die Electron-App, die es ersetzt hat
    • Man muss dann einfach in 12–18 Monaten den Job wechseln. Dann ist es das Problem von jemand anderem

  • Die Aussage „Anthropic-Forscher Nicholas Carlini koordinierte 16 parallele Claude-Agenten, die in Rust einen produktionsreifen C-Compiler schrieben“ stimmt nicht
    Dieser Compiler erzeugte im Vergleich zu gcc/clang deutlich schlechteren Code und ist praktisch nutzlos