Ende der Swift-Einführung – Abschluss des Swift-6.0-Support-Issues im Ladybird-Browser

 (github.com/LadybirdBrowser)
1 Punkte von GN⁺ 2026-02-20 | 1 Kommentare | Auf WhatsApp teilen
  • Das Ladybird-Browserprojekt hat eine Liste von Problemen zusammengestellt, die beim Übergang des Swift-6.0-Supports vom Experiment in den regulären Einsatz auftraten, entschied anschließend jedoch, die Einführung von Swift nicht weiterzuverfolgen
  • Die wichtigsten Hürden betrafen die Interop zwischen Swift und C++, darunter ABI-Inkonsistenzen, zirkuläre Header-Abhängigkeiten und die Unmöglichkeit, bestimmte Typen zurückzugeben; mehrere Punkte wurden nach Swift 6.0.0 behoben
  • Auch im CMake-Build-System wurden Probleme gemeldet, etwa nicht übereinstimmende Deployment-Targets in Swift-+Ninja-Umgebungen, Fehler bei der install_name-Verarbeitung und inkompatible Compiler-Optionen
  • Auch im Ladybird-eigenen Code wurden zahlreiche Build-Instabilitäten festgestellt, darunter die modulemap-Konfiguration der Module AK und LibGfx, Swift-Frontend-Abstürze und Konflikte bei Typ-Namensräumen
  • Diese kumulierten technischen Einschränkungen führten dazu, dass die Swift-Integration eingestellt wurde; daraus folgte die Entscheidung, die Entwicklung mit Fokus auf C++ fortzuführen

Probleme im Zusammenhang mit Swift

  • Es gab zahlreiche Fehler auf Sprach- und ABI-Ebene, die behoben werden mussten, damit der Swift-6.0-Support den experimentellen Status verlassen konnte
    • Beim Open-Source-Build von Swift traten aufgrund nicht übereinstimmender LLVM-Versionen Assertion-Fehler auf
    • Bei der Rückgabe von Optional<CxxValueType> kam es zu ABI-Inkonsistenzen zwischen Compiler und Bridging-Header
    • Unter Ubuntu 22.04 entstanden beim Einbinden des Headers <execution> zirkuläre Modulabhängigkeiten in libstdc++
    • Enthalten waren auch Kompatibilitätsprobleme mit C++23, etwa die fehlende Möglichkeit, swift::Optional<swift::String> zurückzugeben, oder das Scheitern beim Laden des Headers <chrono>
  • Einige Probleme wurden in Releases nach Swift 6.0.0 behoben, andere jedoch nur im main-Branch, sodass sie nicht in stabile Versionen eingeflossen sind
  • Für mehrere Punkte wurden „Workarounds (Umgehungen beim Build)“ vorgeschlagen, diese stellen jedoch keine vollständige Lösung dar

Probleme im Zusammenhang mit CMake

  • In der Kombination aus Swift und Ninja-Build wurde CMAKE_OSX_DEPLOYMENT_TARGET nicht angewendet, was zu zahlreichen Warnungen führte
    • CMAKE_Swift_COMPILER_TARGET musste manuell gesetzt werden
  • Bei aktivierter Richtlinie CMP0157 wurde die Einstellung des install_name-Verzeichnisses ignoriert, sodass eine manuelle Korrektur nötig war
    • Ein entsprechender Fix soll auf CMake 3.29 und 3.30 zurückportiert werden
  • Es gab ein Problem, bei dem Linker-Optionen, die der Swift-Compiler nicht versteht, aus externen Abhängigkeiten weitergereicht wurden

Interne Probleme im Ladybird-Projekt

  • Bei der clang-modulemap-Konfiguration der Module AK und LibGfx kam es zu Konflikten mit System-Headern
    • Beim Einbinden von <math.h> schlug der Build wegen eines Fehlers bei der Modulerkennung fehl
  • Das Swift-Frontend stürzte in Debug-Builds während AK-Containertests ab
    • Umgehbar war dies nur durch Builds im Release-Modus
  • Ein Konflikt im Namensraum des Typs String führte zu einem unerwarteten Abbruch des Swift-Frontends
    • Eine explizite Angabe als AK.String oder Swift.String war erforderlich
  • Bei Verwendung des Swift-Testing-Moduls traten Frontend-Abstürze des Compilers auf; außerdem wurde AK::StringView nicht als CxxSequenceType erkannt

Zusätzliche Verbesserungsbereiche

  • Wenn C++-Funktionen in Swift Optional<CxxType> zurückgeben, kam es zu Anwendungsabstürzen
    • Als temporärer Workaround wurde die Rückgabe eines Arrays der Größe 0 oder 1 verwendet
  • SourceKit-LSP und vscode-swift verlangen compile_commands.json auf Root-Ebene
    • Dies lässt sich durch das Erstellen eines symbolischen Links lösen
  • Unter Linux bestand die Unannehmlichkeit, dass der Pfad <swift/bridging> manuell hinzugefügt werden musste

Offene Fragen

  • Es ist unklar, wie sich in Swift C++-View-Typen oder Byte-Slices ohne Kopie übergeben lassen
  • Swift erkennt eigene Typen wie AK::Optional oder AK::HashMap nicht als gleichwertig zu std::-Typen
  • Auch die Integration des Swift-Garbage-Collectors in Ladybirds Speicherverwaltung war noch ungeklärt

Dieses Issue war zwar ein Dokument zur systematischen Erfassung technischer Hürden für die Swift-6.0-Integration, wurde jedoch abgeschlossen, nachdem das Ladybird-Team die Einführung von Swift eingestellt hatte; damit wurde auch das Issue „Swift 6.0 Blockers“ beendet.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-20
Hacker-News-Kommentare

  • Der Commit zum Entfernen von Swift enthält noch etwas zusätzliche Erklärung.
    Er enthält die Nachricht: „Da es lange keine Fortschritte gab, wurde die Einführung von Swift aufgegeben und aus der Codebasis entfernt.“
    Den zugehörigen Commit gibt es hier.

    • Mehr Kontext ist hier in Issue #933 zusammengefasst.

  • Ich habe Swift 2021 zum ersten Mal ausprobiert und war überrascht, nachdem ich über 10 Jahre mit C#/.NET gearbeitet hatte.
    Ich hielt schon C# für komplex, aber Swift war eine noch deutlich komplexere Sprache.
    Vor allem beim Erstellen von Backend-APIs oder einer Datenzugriffsschicht gab es fast kein Referenzmaterial.
    Das Wissen zu Swift ist größtenteils für Apple-Plattformen aufgebaut, sodass man sich außerhalb davon fast wie ein Pionier fühlt.

    • In den letzten Jahren haben einfache Sprachen wie Python oder Go zwar die These gestärkt, dass „Komplexität schlecht ist“, aber ich finde, dass hohe Ausdrucksstärke einer Sprache der Wartbarkeit auch helfen kann.
      Wie Larry Wall sagte, sollte die Komplexität des Werkzeugs zur Komplexität des Problems passen (mit Verweis auf Raku).
    • Ich bin etwa 2018 von Objective-C zu Swift gewechselt, und anfangs wirkte es wie eine Verbesserung.
      Aber Regeln wie „struct wird per Wert übergeben, class per Referenz“ kollidierten mit dem Prinzip einer „Single Source of Truth“, wodurch sich die Entwicklung langweilig und langsam anfühlte.
      Wegen widersprüchlicher Best Practices in Swift gab es keine Fortschritte, und am Ende wurde mir klar, dass man vielen Ratschlägen nicht trauen konnte.
    • Auf einem M1 MacBook gab es außerdem das Problem, dass sich der Laptop überhitzte, sobald ich ein Vapor-Template kompilierte.
    • Bei mir war es ähnlich. Ich dachte, ich würde es wie Rust schnell lernen, aber das war überhaupt nicht so.
      Es gibt zu viel syntactic sugar, und für dieselbe Sache gibt es Dutzende Wege, sodass ich ständig in der Sprachreferenz nachsehen musste.
    • Deshalb frage ich mich, ob du am Ende wieder zu C#/.NET zurückgekehrt bist.

  • Unabhängig von der Sprache hoffe ich, dass sich Ladybird später auf eine nutzerfreundliche JavaScript-Implementierung konzentriert.
    Es ist problematisch, dass JS für Nutzer-Tracking, das Blockieren von Einfügen oder das exzessive Sammeln von Geräteinformationen missbraucht wird.
    Wenn wie bei Tor standardisierte Spoofing-Werte für alle Nutzer gemeldet würden, könnte das dem Schutz der Privatsphäre helfen.

    • So ein Ansatz könnte aber auf vielen Websites irrtümlich als Bot-Erkennung gewertet werden und den Zugriff blockieren.
      Als umschaltbare Option wäre das okay, aber als Standard dürfte die Akzeptanz schwierig werden.
    • Einen Browser, der Webstandards ignoriert und eigenständig anders funktioniert, würde ich persönlich niemals benutzen wollen.

  • Dass Swift entfernt wurde, ist interessant. Die Gründe wurden nicht klar erklärt, daher bin ich neugierig.
    Wenn es nur unter Linux läuft, würde ich es später trotzdem einmal testen.

    • Meiner Ansicht nach haben sie wohl wegen wiederholter Build-Konflikte aufgegeben.
      Es gab Probleme damit, dass Swift nicht mehrere Bibliotheken mit unterschiedlichen C++-Versionen gleichzeitig importieren konnte oder dass Operator-Versionen kollidierten.
      Swift ist zwar eine gute Sprache, aber für die nachträgliche Einführung in ein bereits großes Projekt war es wohl zu komplex.

  • Ich frage mich, warum Ladybird Swift ausprobiert hat. Ich hätte gedacht, dass Rust eine bessere C++-Interoperabilität hat.
    Auch Swifts GC scheint für Browser-Performance nachteilig zu sein.

    • Andreas Kling erwähnte auf Twitter, dass Swift im Vergleich zu Rust bei der Objektorientierung und der C++-Anbindung besser sei.
      Link1, Link2
    • Das ist ähnlich wie der Grund, warum Rust in der Spieleentwicklung unbequem sein kann. Der borrow checker passt nicht gut zu zyklischen Referenzstrukturen.
      Es gibt Workarounds, aber sie kosten Produktivität.
    • Swift hat tatsächlich eine ziemlich gute Interoperabilität, wie in der C++-Interop-Dokumentation beschrieben.
      Für Ladybird scheint es allerdings nicht gereicht zu haben.
    • Andreas Kling sagte, dass Rust nicht genug objektorientierte Funktionen habe und deshalb für GUI-Entwicklung nachteilig sei.
      Früher entstand in SerenityOS sogar die Sprache Jakt, aber am Ende scheint man doch wieder bei C++ gelandet zu sein.
    • Soweit ich mich erinnere, wurde Rust wegen der DOM-Hierarchie oder allgemeiner OOP-Probleme einmal abgelehnt.
      Die frühere Diskussion dazu findet sich in diesem Beitrag.

  • Es überrascht mich nicht, dass Swift entfernt wurde, weil es eine zu stark von Apple abhängige Sprache ist.
    Es reicht völlig, nur die sicheren Teile von C++ sauber zu verwenden, und tatsächlich sind die meisten Browser in C++ geschrieben.

    • Allerdings sind alle Browser dadurch nur in C++ gefangen.
      Chromium und Firefox ersetzen schrittweise Teile durch sicherere Sprachen, und einen neuen Browser erneut in C++ zu schreiben hieße, die Fehler der Vergangenheit zu wiederholen.
      Die Verwendung von C++ ist ein Erbe aus der KHTML-Zeit von 1998.
    • Ich weiß nicht genau, was mit einem „modernen speichersicheren C++-Subset“ konkret gemeint ist.
      Sind damit auch neuere STL-Features wie string_view gemeint? Von vollständiger Speichersicherheit ist das immer noch weit entfernt.
    • Soweit ich weiß, wurde Rust bei Mozilla entwickelt, daher frage ich mich, ob Mozilla selbst in Rust geschrieben ist.
    • Wie dem auch sei: In Bereichen, die hohe Performance verlangen, dürfte Swift C++ kaum schlagen.
      Abgesehen von einigen Benchmarks ist es in realen Programmen fast immer langsamer.

  • Schade, dass Swift entfernt wurde. Ich frage mich, ob damit die eigene Sprache Jakt wieder als Kandidat auf den Tisch kommt.

    • Ladybird wurde bereits von SerenityOS getrennt, und Jakt ist nicht ihre Sprache.
      Ich halte es für unwahrscheinlich, dass noch einmal eine neue Sprache eingeführt wird.
    • Mich beunruhigt persönlich, dass das Projekt zu oft die Richtung wechselt.
      Für ein Projekt, das durch externe Förderung betrieben wird, dürfte so etwas langfristig schwer tragfähig sein.
    • Ich verstehe nicht, warum man Rust nicht nutzt. Vielleicht ist es einfach eine Fixierung auf C++.

  • Ich halte Swift letztlich nur für eine Spielzeugsprache von Apple.
    Apple wird nicht zulassen, dass sie darüber hinauswächst.

  • Die Mac-UI von Ladybird ist eine dünne Schicht auf AppKit.
    Sie ist nicht in Swift, sondern in Objective-C++ geschrieben.
    Siehe den Quellcode.

    • Ich bin die Person, die diesen Code ursprünglich geschrieben hat.
      Er entstand lange vor der Einführung von Swift, noch in der SerenityOS-Zeit, und ich habe Objective-C++ nur verwendet, weil es mir vertraut war.

  • Als damals von einer Umstellung auf Swift die Rede war, habe ich das kritisiert.
    Ich fand, Swift sei schlecht entworfen, langsam beim Kompilieren und habe wenig Aussicht, sich als Systemsprache zu etablieren.
    Es gab auch keine Experten, daher halte ich die jetzige Entscheidung für richtig.

    • Swift wirkt zwar wie Open Source, aber tatsächlich hält Apple alle Entscheidungsbefugnisse in der Hand.
      Funktionen wie Concurrency oder Swift Testing wurden ebenfalls nach Apples Bedarf vorangetrieben.
      Cross-Platform-Arbeit wird größtenteils separat von kleinen Teams betrieben.
    • Ich erkenne die Probleme von Swift an, aber die Aussage, es habe „keine Experten gegeben“, ist übertrieben.
      Auch abgesehen von Chris Lattner waren die Swift-Leads in der C++-Community anerkannte Persönlichkeiten.
    • Der Kern von Swift ist weniger die Sprache selbst als die standardisierte ABI.
      Es wäre schön, wenn das Rust-Lager neben C auch die Swift-ABI für FFI unterstützen würde.
    • Dann würde mich interessieren, welche Sprache du stattdessen empfehlen würdest.
    • Gilt Ähnliches auch für Go? Ich würde gern wissen, was heute die am breitesten akzeptierte Wahl ist.