Swift benimsenmesi durduruldu – Ladybird tarayıcısında Swift 6.0 desteği sorunu kapatıldı

 (github.com/LadybirdBrowser)
1 puan yazan GN⁺ 2026-02-20 | 1 yorum | WhatsApp'ta paylaş
  • Ladybird tarayıcı projesi, Swift 6.0 desteğini deneysel aşamadan resmî kullanıma taşırken ortaya çıkan sorunların listesini derledi; ancak sonrasında Swift benimsenmesini artık sürdürmeme kararı aldı
  • Başlıca engeller arasında Swift ile C++ birlikte çalışabilirliği (Interop) ile ilgili ABI uyumsuzlukları, header döngüsel bağımlılıkları ve bazı türlerin döndürülememesi yer aldı; bu maddelerin bir kısmı Swift 6.0.0 sonrasında düzeltildi
  • CMake derleme sistemi tarafında da Swift + Ninja ortamında dağıtım hedefi uyumsuzluğu, install_name işleme hatası ve uyumsuz derleyici seçenekleri gibi sorunlar bildirildi
  • Ladybird’ün kendi kodunda da AK ve LibGfx modüllerinin modulemap yapılandırması, Swift frontend çökmesi, tür namespace çakışmaları gibi çok sayıda derleme kararsızlığı tespit edildi
  • Biriken bu teknik kısıtlar nedeniyle Swift entegrasyonu durduruldu ve bu da C++ merkezli geliştirmeyi sürdürme kararıyla sonuçlandı

Swift ile ilgili sorunlar

  • Swift 6.0 desteğini deneysel aşamadan çıkarmak için çözülmesi gereken çok sayıda dil ve ABI düzeyi hata bulunuyordu
    • LLVM sürüm uyumsuzluğu nedeniyle Swift açık kaynak derlemesinde assertion hatası oluşuyordu
    • Optional<CxxValueType> döndürülürken derleyici ile bridging header arasında ABI uyumsuzluğu yaşanıyordu
    • Ubuntu 22.04 ortamında <execution> header’ı eklendiğinde libstdc++ modül döngüsel bağımlılığı oluşuyordu
    • swift::Optional<swift::String> döndürülememesi ve <chrono> header’ının yüklenememesi gibi C++23 uyumluluk sorunları da buna dahildi
  • Bazı sorunlar Swift 6.0.0 sonrasındaki sürümlerde düzeltildi; ancak bir kısmı yalnızca main branch üzerinde çözüldüğü için kararlı sürümlere yansımadı
  • Birçok maddede “workaround (geçici derleme yöntemi)” sunuldu, ancak bunlar tam çözüm değildi

CMake ile ilgili sorunlar

  • Swift ile Ninja derleme kombinasyonunda CMAKE_OSX_DEPLOYMENT_TARGET uygulanmadığı için çok sayıda uyarı oluşuyordu
    • CMAKE_Swift_COMPILER_TARGET değerinin elle ayarlanması gerekiyordu
  • CMP0157 ilkesi etkinleştirildiğinde install_name dizin ayarı yok sayılıyor, bu yüzden elle düzeltme gerekiyordu
    • İlgili düzeltmenin CMake 3.29 ve 3.30’a backport edilmesi planlanıyordu
  • Swift derleyicisinin anlamadığı link seçeneklerinin harici bağımlılıklardan aktarılması sorunu da vardı

Ladybird projesi içindeki sorunlar

  • AK ve LibGfx modüllerinin clang module map yapılandırmasında sistem header’larıyla çakışma yaşanıyordu
    • <math.h> eklendiğinde modül tanıma hatası yüzünden derleme başarısız oluyordu
  • Swift frontend’i, AK container testleri sırasında debug derlemesinde çöküyordu
    • Bu durum yalnızca release modunda derleyerek aşılabiliyordu
  • String türü namespace çakışması nedeniyle Swift frontend’i beklenmedik şekilde sonlanıyordu
    • AK.String veya Swift.String şeklinde açıkça belirtilmesi gerekiyordu
  • Swift Testing modülü kullanıldığında derleyici frontend çökmesi ve AK::StringView için CxxSequenceType tanınmaması sorunları vardı

Ek iyileştirme maddeleri

  • Swift’te C++ fonksiyonlarının Optional<CxxType> döndürmesi durumunda uygulama çökmesi yaşanıyordu
    • Geçici çözüm olarak boyutu 0 veya 1 olan dizi döndürme kullanılıyordu
  • SourceKit-LSP ve vscode-swift, kök seviyede compile_commands.json istiyordu
    • Bu durum sembolik bağlantı oluşturularak çözülebiliyordu
  • Linux ortamında <swift/bridging> yolunun elle eklenmesi gerekmesi gibi bir kullanım zorluğu da vardı

Cevapsız sorular

  • Swift ile C++’taki view türlerinin veya byte slice’ların kopyasız biçimde nasıl aktarılacağı belirsizdi
  • Swift, AK::Optional, AK::HashMap gibi özel türleri std:: türleriyle eşdeğer olarak tanıyamıyordu
  • Swift çöp toplayıcısı ile Ladybird’ün bellek yönetiminin nasıl entegre edileceği de henüz net değildi

Bu issue, Swift 6.0 entegrasyonu için teknik engelleri sistemli biçimde kayda geçiren bir belgeydi; ancak daha sonra Ladybird ekibi Swift benimsenmesini durdurunca “Swift 6.0 Blockers” issue’su kapatıldı.

İlgili okumalar

1 yorum

 
GN⁺ 2026-02-20
Hacker News görüşleri

  • Swift’i kaldıran commit’te biraz ek açıklama var
    “Uzun süredir **ilerleme olmadığı için Swift benimsenmesinden vazgeçildi ve kod tabanından kaldırıldı” mesajı yer alıyor
    İlgili commit’e buradan bakılabilir

    • Daha ayrıntılı bağlam issue #933’te derlenmiş

  • Swift’i ilk kez 2021’de denedim; 10 yıldan fazla C#/.NET geçmişinden sonra gelince şaşırmıştım
    C#’ın da karmaşık olduğunu düşünüyordum ama Swift ondan çok daha karmaşık bir dil gibi geldi
    Özellikle backend API’leri ya da veri erişim katmanları oluştururken başvurulacak kaynak neredeyse yoktu
    Swift hakkındaki bilgi birikimi çoğunlukla Apple platformları için oluşmuş durumda, bu yüzden onun dışındaki alanlarda neredeyse öncü olmak zorunda kalıyorsunuz

    • Son birkaç yılda Python ya da Go gibi basit diller “karmaşıklık kötüdür” iddiasını güçlendirdi, ama bir dilin ifade gücü yüksekse bunun bakım açısından faydalı olabileceğini düşünüyorum
      Larry Wall’un dediği gibi, aracın karmaşıklığı problemin karmaşıklığına uygun olmalı (Raku referansı)
    • Ben de 2018 civarında Objective-C’den Swift’e geçtim ve başta iyileşme gibi gelmişti
      Ama “struct değerle aktarılır, class referansla aktarılır” gibi kurallarla “tek bir doğru kaynak tutma” ilkesi çakışınca geliştirme deneyimi yorucu ve yavaş hale geldi
      Swift’in birbiriyle çelişen best practice’leri yüzünden ilerleyemedim ve sonunda verilen birçok tavsiyeye güvenilemeyeceğini fark ettim
    • M1 MacBook’ta Vapor şablonunu her derlediğimde dizüstü bilgisayarın aşırı ısınması gibi bir sorunum da vardı
    • Benim deneyimim de benzerdi. Rust gibi hızlı öğrenilir sanmıştım ama hiç öyle olmadı
      Fazla fazla sözdizimi şekeri var ve aynı işi yapmanın düzinelerce yolu olduğu için sürekli dil referansına bakmak zorunda kalıyordum
    • Peki sonunda yeniden C#/.NET’e mi döndün diye merak ediyorum

  • Dil ne olursa olsun, umarım Ladybird ileride kullanıcı dostu bir JavaScript uygulamasına odaklanır
    JS’in kullanıcı etkinliğini takip etmek, yapıştırmayı engellemek ya da cihaz hakkında aşırı bilgi toplamak için kötüye kullanılması sorunlu
    Tor’daki gibi kullanıcılar arasında standartlaştırılmış spoofing değerleri raporlanması gizliliği korumaya yardımcı olabilir gibi görünüyor

    • Ama bu yaklaşım birçok web sitesinde bot tespiti sanılıp erişimin engellenmesine yol açabilir
      Bir aç/kapa seçeneği olarak sunulması makul, ama varsayılan olursa benimsenmesi zor olur gibi
    • Web standartlarını yok sayıp kendine göre davranan bir tarayıcıyı şahsen asla kullanmak istemem

  • Swift’in kaldırılması ilginç. Sebep açıkça anlatılmamış, bu yüzden merak ettim
    Linux’ta çalışır hale gelirse ileride test etmeyi düşünüyorum

    • Bana kalırsa tekrar eden build çakışmaları yüzünden vazgeçilmiş gibi görünüyor
      Sorun, Swift’in birden fazla C++ sürümü kütüphanesini aynı anda içe aktaramaması ya da operatör sürümü çakışmalarının ortaya çıkmasıydı
      Swift iyi bir dil ama zaten büyük olan bir projeye sonradan eklemek için fazla karmaşık kalmış olabilir

  • Ladybird’ün neden Swift’i denediğini merak ediyorum. Rust daha iyi C++ birlikte çalışabilirliği sunmuyor mu diye düşünüyorum
    Swift’in GC’si de tarayıcı performansı için dezavantajlı olur gibi

    • Andreas Kling Twitter’da, Swift vs Rust karşılaştırmasında Swift’in nesne yönelimli destek ve C++ entegrasyonu açısından daha iyi olduğunu söylemişti
      link1, link2
    • Bu, Rust’ın oyun geliştirmede zorlayıcı olmasına benziyor. borrow checker, döngüsel referans yapılarıyla pek iyi anlaşmıyor
      Etrafından dolaşmanın yolları var ama üretkenliği düşürüyor
    • Swift aslında C++ interop dokümanında da görüldüğü gibi birlikte çalışabilirlik konusunda epey iyi
      Ama anlaşılan Ladybird için yeterli olmamış
    • Andreas Kling, Rust’ın nesne yönelimli özellikler bakımından yetersiz olduğu için GUI geliştirmede dezavantajlı olduğunu söylemişti
      Geçmişte SerenityOS için Jakt adlı bir dil de geliştirmişti ama sonunda yine C++’a dönmüş gibi görünüyor
    • Rust’ın DOM hiyerarşisi ya da OOP sorunları nedeniyle reddedildiğini hatırlıyorum
      İlgili eski tartışma bu gönderide

  • Swift Apple’a fazla bağımlı bir dil, o yüzden şaşırtıcı değil
    C++’ın güvenli kısımlarını düzgün kullanmak yeterli olur ve zaten tarayıcıların çoğu C++ ile yazılıyor

    • Ama aslında tüm tarayıcılar C++’a mahkûm kalmış durumda
      Chromium ve Firefox kademeli olarak daha güvenli dillere geçmeye çalışıyor; yeni bir tarayıcıyı tekrar C++ ile yazmak geçmişin hatalarını tekrarlamak olur
      C++ kullanımı 1998’deki KHTML döneminden kalma bir miras
    • “Modern, bellek güvenli C++ alt kümesi” ile tam olarak ne kastedildiğini bilmiyorum
      string_view gibi yeni STL özelliklerini de içeriyor mu? Yine de tam bellek güvenliğinden hâlâ uzak olurdu
    • Rust’ın Mozilla’da geliştirildiğini biliyorum; peki Mozilla’nın kendisi de Rust ile mi yazıldı diye merak ediyorum
    • Her halükârda Swift’in yüksek performans gereken alanlarda C++’ı geçmesi zor
      Bazı benchmark’lar dışında gerçek programlarda neredeyse her zaman daha yavaş kalıyor

  • Swift’in kaldırılması üzücü. Acaba bu durumda kendi dilleri Jakt yeniden aday olur mu

    • Ladybird zaten SerenityOS’tan ayrıldı ve Jakt onların dili değil
      Yeni bir dil benimseme ihtimallerini düşük görüyorum
    • Şahsen projenin çok sık yön değiştirmesi beni endişelendiriyor
      Dış sponsorlukla yürüyen bir proje böyle olursa uzun vadede sürdürülebilirliği zor olabilir
    • Neden Rust kullanmadıklarını anlamakta zorlanıyorum. Acaba mesele C++ takıntısı mı diye düşünüyorum

  • Swift’in sonuçta sadece Apple’ın oyuncak dili olduğunu düşünüyorum
    Apple onun bunun ötesine büyümesine izin vermeyecektir

  • Ladybird’ün Mac UI’ı, AppKit üzerine eklenmiş ince bir katman
    Swift değil, Objective-C++ ile yazılmış
    Kaynak kodu burada

    • O kodu ilk yazan kişi benim
      Swift’in benimsenmesinden çok önce, SerenityOS döneminde yapmıştım; Objective-C++ kullanmamın nedeni sadece aşina olduğum dil olmasıydı

  • Geçmişte Swift’e geçileceği söylenince bunu eleştirmiştim
    Swift’in tasarımının dağınık olduğunu, derleme hızının da yavaş olduğunu ve sistem dili olarak büyüme ihtimalinin düşük olduğunu düşünüyordum
    Ortada uzman da yoktu; bu yüzden bu kararın iyi olduğunu düşünüyorum

    • Swift açık kaynakmış gibi görünse de gerçekte tüm karar yetkisi Apple’ın elinde
      Concurrency ya da Swift Testing gibi özellikler de Apple’ın ihtiyaçları doğrultusunda ileri itilen örneklerdi
      Cross-platform çalışmaların çoğu ayrı çalışan küçük ekipler tarafından yürütülüyor
    • Swift’in sorunlarını kabul ediyorum ama “uzman yoktu” demek abartılı
      Chris Lattner dışında bile Swift liderleri C++ topluluğunda saygı gören kişilerdi
    • Swift’in asıl önemli yanı dilin kendisinden çok standart ABI’si
      Rust ekosisteminin C’nin yanında Swift ABI’yi de FFI için desteklemesi güzel olurdu
    • O halde hangi dili önerdiğini merak ediyorum
    • Go da benzer durumda mı? Bugün üzerinde en çok uzlaşılan seçenek hangisi, bilmek isterim