Penghentian adopsi Swift – penutupan isu dukungan Swift 6.0 di browser Ladybird

 (github.com/LadybirdBrowser)
1 poin oleh GN⁺ 2026-02-20 | 1 komentar | Bagikan ke WhatsApp
  • Proyek browser Ladybird telah merangkum daftar masalah yang muncul dalam proses mengubah dukungan Swift 6.0 dari tahap eksperimental menjadi resmi, tetapi kemudian memutuskan untuk tidak lagi melanjutkan adopsi Swift
  • Faktor penghambat utama mencakup ketidakcocokan ABI terkait interoperabilitas (interop) Swift dan C++, dependensi siklik header, ketidakmampuan mengembalikan tipe tertentu, dan beberapa di antaranya telah diperbaiki setelah Swift 6.0.0
  • Di sistem build CMake juga dilaporkan masalah seperti ketidakcocokan target deployment pada lingkungan Swift + Ninja, kesalahan penanganan install_name, dan opsi kompilasi yang tidak kompatibel
  • Pada kode Ladybird sendiri, ditemukan banyak ketidakstabilan build seperti konfigurasi modulemap pada modul AK dan LibGfx, crash frontend Swift, serta konflik namespace tipe
  • Karena akumulasi keterbatasan teknis ini, integrasi Swift dihentikan, yang berujung pada keputusan untuk tetap mempertahankan pengembangan yang berpusat pada C++

Masalah terkait Swift

  • Terdapat banyak bug pada level bahasa dan ABI yang harus diselesaikan agar dukungan Swift 6.0 bisa keluar dari tahap eksperimental
    • Kegagalan assertion saat build open source Swift akibat ketidakcocokan versi LLVM
    • Masalah ketidakcocokan ABI antara compiler dan bridging header saat mengembalikan Optional<CxxValueType>
    • Muncul dependensi siklik modul libstdc++ saat menyertakan header <execution> di lingkungan Ubuntu 22.04
    • Termasuk masalah kompatibilitas C++23 seperti tidak bisa mengembalikan swift::Optional<swift::String> dan kegagalan memuat header <chrono>
  • Sebagian masalah telah diperbaiki pada rilis setelah Swift 6.0.0, tetapi sebagian lain hanya terselesaikan di branch main sehingga belum masuk ke versi stabil
  • Di berbagai poin diajukan “workaround (metode build alternatif)”, tetapi itu bukan solusi menyeluruh

Masalah terkait CMake

  • Pada kombinasi build Swift dan Ninja, CMAKE_OSX_DEPLOYMENT_TARGET tidak diterapkan sehingga muncul banyak peringatan
    • Perlu menetapkan CMAKE_Swift_COMPILER_TARGET secara manual
  • Saat kebijakan CMP0157 diaktifkan, pengaturan direktori install_name diabaikan sehingga perlu perbaikan manual
    • Perbaikan terkait direncanakan di-backport ke CMake 3.29 dan 3.30
  • Ada masalah ketika opsi linker yang tidak dipahami compiler Swift diteruskan dari dependensi eksternal

Masalah internal proyek Ladybird

  • Saat menyusun clang module map untuk modul AK dan LibGfx, terjadi konflik dengan header sistem
    • Build gagal karena kesalahan pengenalan modul saat menyertakan <math.h>
  • Frontend Swift crash pada build debug selama pengujian container AK
    • Hanya bisa dihindari dengan build mode rilis
  • Frontend Swift berhenti secara abnormal akibat konflik namespace pada tipe String
    • Perlu penentuan eksplisit sebagai AK.String atau Swift.String
  • Saat menggunakan modul Swift Testing, terdapat crash frontend compiler, serta masalah AK::StringView tidak dikenali sebagai CxxSequenceType

Poin perbaikan tambahan

  • Aplikasi crash ketika fungsi C++ di Swift mengembalikan Optional<CxxType>
    • Sebagai solusi sementara, digunakan pengembalian array berukuran 0 atau 1
  • SourceKit-LSP dan vscode-swift memerlukan compile_commands.json di level root
    • Dapat diatasi dengan membuat symbolic link
  • Di lingkungan Linux, ada ketidaknyamanan karena jalur <swift/bridging> harus ditambahkan secara manual

Pertanyaan yang belum terjawab

  • Belum jelas bagaimana di Swift meneruskan view type atau byte slice milik C++ tanpa penyalinan
  • Swift tidak dapat mengenali tipe internal seperti AK::Optional, AK::HashMap, dan lainnya sebagai setara dengan tipe std::
  • Cara integrasi garbage collector Swift dengan manajemen memori Ladybird juga masih belum ditentukan

Isu ini awalnya merupakan dokumen yang mencatat secara sistematis hambatan teknis untuk integrasi Swift 6.0, tetapi setelah tim Ladybird menghentikan adopsi Swift, isu “Swift 6.0 Blockers” pun ditutup.

Bacaan terkait

1 komentar

 
GN⁺ 2026-02-20
Komentar Hacker News

  • Commit penghapusan Swift memiliki sedikit penjelasan tambahan
    Ada pesan yang berbunyi, “Karena sudah lama tidak ada kemajuan, adopsi Swift dibatalkan dan dihapus dari codebase”
    Commit terkait bisa dilihat di sini

  • Saya pertama kali mencoba Swift pada 2021, dan setelah lebih dari 10 tahun memakai C#/.NET saya cukup terkejut
    Saya pikir C# sudah kompleks, tetapi Swift adalah bahasa yang jauh lebih kompleks
    Terutama saat membuat backend API atau lapisan akses data, hampir tidak ada referensi yang bisa dijadikan acuan
    Pengetahuan tentang Swift sebagian besar terakumulasi untuk platform Apple, jadi di luar itu rasanya kita harus menjadi perintis

    • Dalam beberapa tahun terakhir, bahasa sederhana seperti Python atau Go memperkuat argumen bahwa “kompleksitas itu buruk”, tetapi saya pikir daya ekspresif bahasa yang tinggi justru bisa membantu pemeliharaan
      Seperti kata Larry Wall, kompleksitas alat harus disesuaikan dengan kompleksitas masalahnya (menyebut Raku)
    • Saya berpindah dari Objective-C ke Swift sekitar 2018, dan awalnya terasa seperti peningkatan
      Namun aturan seperti “struct dikirim berdasarkan nilai, class dikirim berdasarkan referensi” berbenturan dengan prinsip “mempertahankan satu sumber kebenaran”, sehingga pengalaman pengembangannya terasa membosankan dan lambat
      Karena best practice Swift saling bertentangan, tidak ada kemajuan, dan pada akhirnya saya sadar banyak sarannya tidak bisa benar-benar dipercaya
    • Ada juga masalah laptop menjadi terlalu panas setiap kali mengompilasi template Vapor di MacBook M1
    • Saya juga mengalami hal serupa. Saya kira akan cepat terbiasa seperti Rust, tetapi ternyata sama sekali tidak
      Terlalu banyak syntax sugar, dan ada puluhan cara untuk melakukan hal yang sama, jadi saya harus terus membuka referensi bahasa
    • Jadi saya penasaran apakah pada akhirnya Anda kembali lagi ke C#/.NET

  • Apa pun bahasanya, saya berharap Ladybird nantinya fokus pada implementasi JavaScript yang ramah pengguna
    Masalahnya adalah JS disalahgunakan untuk melacak aktivitas pengguna, memblokir paste, atau mengumpulkan terlalu banyak informasi perangkat
    Jika seperti Tor dan melaporkan nilai spoofing yang distandardisasi antar pengguna, itu tampaknya bisa membantu privasi

    • Namun pendekatan seperti ini bisa dianggap sebagai deteksi bot oleh banyak situs web dan membuat akses diblokir
      Menyediakannya sebagai opsi toggle tidak masalah, tetapi jika dijadikan default sepertinya akan sulit diadopsi
    • Secara pribadi saya sama sekali tidak ingin memakai browser yang mengabaikan standar web dan bertindak sendiri

  • Penghapusan Swift ini menarik. Alasannya tidak dijelaskan dengan jelas, jadi saya penasaran
    Kalau nanti sudah bisa berjalan di Linux, saya ingin mencobanya

    • Menurut saya mereka menyerah karena konflik build yang terus berulang
      Masalahnya adalah Swift tidak bisa mengimpor library beberapa versi C++ sekaligus, atau muncul konflik versi operator
      Swift memang bahasa yang bagus, tetapi mungkin terlalu rumit untuk ditambahkan belakangan ke proyek yang sudah besar

  • Saya penasaran kenapa Ladybird mencoba Swift. Saya kira Rust punya interoperabilitas C++ yang lebih baik
    GC Swift juga tampaknya akan merugikan performa browser

    • Andreas Kling menyebut di Twitter bahwa dalam perbandingan “Swift vs Rust”, Swift lebih baik dalam dukungan berorientasi objek dan integrasi C++
      Link1, Link2
    • Alasannya mirip dengan kenapa Rust terasa kurang nyaman untuk pengembangan game. borrow checker kurang cocok dengan struktur referensi melingkar
      Ada cara mem-bypass-nya, tetapi produktivitas menurun
    • Swift sebenarnya punya interoperabilitas yang cukup baik, seperti yang tertulis dalam dokumentasi C++ interop
      Hanya saja tampaknya itu belum cukup untuk Ladybird
    • Andreas Kling mengatakan Rust kurang memiliki fitur berorientasi objek, sehingga kurang menguntungkan untuk pengembangan GUI
      Dulu mereka juga sempat membuat bahasa bernama Jakt di SerenityOS, tetapi pada akhirnya tampaknya kembali ke C++
    • Saya ingat Rust pernah ditolak karena masalah hierarki DOM atau masalah OOP
      Diskusi lama terkait ada di posting ini

  • Tidak mengejutkan karena Swift terlalu bergantung pada Apple
    Cukup gunakan bagian C++ yang aman dengan baik, dan memang sebagian besar browser ditulis dengan C++

    • Tetapi semua browser itu hanya terjebak di C++
      Chromium dan Firefox sedang bertahap menggantinya dengan bahasa yang lebih aman, dan menulis browser baru lagi dengan C++ sama saja mengulangi kesalahan masa lalu
      Penggunaan C++ adalah warisan dari era KHTML pada 1998
    • Saya tidak tahu persis apa yang dimaksud dengan “subset C++ modern yang aman untuk memori”
      Apakah itu mencakup fitur STL modern seperti string_view? Tetap saja itu masih jauh dari keamanan memori yang sepenuhnya utuh
    • Saya tahu Rust dikembangkan di Mozilla, tetapi saya penasaran apakah Mozilla sendiri ditulis dengan Rust
    • Bagaimanapun juga, Swift sulit mengalahkan C++ di area yang membutuhkan performa tinggi
      Di luar beberapa benchmark tertentu, dalam program nyata hampir selalu lebih lambat

  • Sayang sekali Swift dihapus. Jadi apakah bahasa internal Jakt kembali menjadi kandidat?

    • Ladybird sudah dipisahkan dari SerenityOS, dan Jakt bukan bahasa milik mereka
      Saya rasa kemungkinan mereka mengadopsi bahasa baru rendah
    • Secara pribadi saya khawatir proyek ini terlalu sering mengubah arah
      Jika proyek yang dijalankan dengan sponsor eksternal seperti ini terus begitu, akan sulit bertahan dalam jangka panjang
    • Saya kesal kenapa mereka tidak memakai Rust. Apa ini semacam obsesi pada C++?

  • Saya pikir Swift pada akhirnya cuma bahasa mainan Apple
    Apple tidak akan membiarkannya berkembang lebih jauh dari itu

  • UI Mac Ladybird adalah lapisan tipis di atas AppKit
    Itu ditulis dengan Objective-C++, bukan Swift
    Lihat kode sumber

    • Saya orang yang pertama menulis kode itu
      Itu dibuat jauh sebelum adopsi Swift, pada masa SerenityOS, jadi saya memakai Objective-C++ hanya karena itu bahasa yang familiar bagi saya

  • Dulu saya mengkritik saat mereka mengatakan akan beralih ke Swift
    Menurut saya desain Swift berantakan, kecepatan kompilasinya lambat, dan kecil kemungkinan tumbuh sebagai bahasa sistem
    Karena juga tidak ada ahli yang tersedia, saya rasa keputusan kali ini adalah langkah yang tepat

    • Swift tampak seperti open source, tetapi pada kenyataannya Apple memegang semua kewenangan pengambilan keputusan
      Fitur seperti Concurrency atau Swift Testing juga merupakan contoh yang didorong sesuai kebutuhan Apple
      Pekerjaan lintas platform sebagian besar dijalankan terpisah oleh tim kecil
    • Saya mengakui ada masalah pada Swift, tetapi mengatakan “tidak ada ahli” itu berlebihan
      Bahkan selain Chris Lattner, para lead Swift adalah tokoh yang diakui di komunitas C++
    • Inti Swift bukan hanya bahasanya sendiri, tetapi ABI standar-nya
      Akan bagus jika kubu Rust mendukung Swift ABI selain C sebagai FFI
    • Kalau begitu saya penasaran bahasa apa yang Anda rekomendasikan
    • Apakah Go juga mirip? Saya ingin tahu apa pilihan yang paling banyak disepakati saat ini