Ngừng áp dụng Swift – khép lại vấn đề hỗ trợ Swift 6.0 của trình duyệt Ladybird

 (github.com/LadybirdBrowser)
1 điểm bởi GN⁺ 2026-02-20 | 1 bình luận | Chia sẻ qua WhatsApp
  • Dự án trình duyệt Ladybird đã tổng hợp danh sách các vấn đề phát sinh trong quá trình chuyển hỗ trợ Swift 6.0 từ giai đoạn thử nghiệm sang chính thức, nhưng sau đó quyết định không tiếp tục thúc đẩy việc áp dụng Swift nữa
  • Trở ngại chính là các vấn đề liên quan đến khả năng tương tác (interop) giữa Swift và C++ như không khớp ABI, phụ thuộc vòng giữa các header, không thể trả về một số kiểu nhất định; nhiều mục đã được sửa sau Swift 6.0.0
  • Trong hệ thống build CMake, cũng có các vấn đề được báo cáo như không khớp deployment target trong môi trường Swift + Ninja, lỗi xử lý install_name, và các tùy chọn biên dịch không tương thích
  • Ngay trong mã nguồn của Ladybird, cũng đã xác nhận nhiều điểm bất ổn khi build như cấu hình modulemap của AK và LibGfx, Swift frontend bị crash, xung đột namespace kiểu dữ liệu
  • Do các ràng buộc kỹ thuật tích lũy này, việc tích hợp Swift đã bị dừng lại, dẫn đến quyết định tiếp tục duy trì phát triển xoay quanh C++

Các vấn đề liên quan đến Swift

  • Có nhiều bug ở cấp độ ngôn ngữ và ABI cần được giải quyết để đưa hỗ trợ Swift 6.0 ra khỏi giai đoạn thử nghiệm
    • Xảy ra lỗi assertion khi build bản mã nguồn mở của Swift do không khớp phiên bản LLVM
    • Vấn đề không khớp ABI giữa compiler và bridging header khi trả về Optional<CxxValueType>
    • Trên Ubuntu 22.04, khi include header <execution> thì phát sinh phụ thuộc vòng của mô-đun libstdc++
    • Bao gồm cả các vấn đề tương thích C++23 như không thể trả về swift::Optional<swift::String>, không tải được header <chrono>
  • Một số vấn đề đã được sửa trong các bản phát hành sau Swift 6.0.0, nhưng một số khác chỉ được giải quyết trên nhánh main nên chưa xuất hiện trong bản ổn định
  • Ở nhiều mục có đưa ra “workaround (cách build lách tạm thời)”, nhưng đó không phải là giải pháp hoàn chỉnh

Các vấn đề liên quan đến CMake

  • Khi kết hợp Swift với build bằng Ninja, CMAKE_OSX_DEPLOYMENT_TARGET không được áp dụng, gây ra nhiều cảnh báo
    • Cần tự thiết lập CMAKE_Swift_COMPILER_TARGET
  • Khi bật chính sách CMP0157, thiết lập thư mục install_name bị bỏ qua, nên phải sửa thủ công
    • Bản vá liên quan dự kiến sẽ được backport vào CMake 3.29 và 3.30
  • Tồn tại vấn đề các tùy chọn link mà compiler Swift không hiểu được truyền từ các dependency bên ngoài

Các vấn đề nội bộ trong dự án Ladybird

  • Khi cấu hình clang module map của các mô-đun AK và LibGfx, xảy ra xung đột với system header
    • Khi include <math.h>, build thất bại do lỗi nhận diện mô-đun
  • Swift frontend crash ở bản build debug trong quá trình test container của AK
    • Chỉ có thể tránh bằng cách build ở chế độ release
  • Xung đột namespace của kiểu String khiến Swift frontend kết thúc bất thường
    • Cần chỉ định tường minh là AK.String hoặc Swift.String
  • Khi dùng mô-đun Swift Testing, tồn tại lỗi crash của compiler frontend và vấn đề AK::StringView không được nhận diện là CxxSequenceType

Các hạng mục cải thiện bổ sung

  • Trong Swift, khi hàm C++ trả về Optional<CxxType> thì ứng dụng bị crash
    • Giải pháp tạm thời là trả về mảng có kích thước 0 hoặc 1
  • SourceKit-LSP và vscode-swift yêu cầu compile_commands.json ở cấp thư mục gốc
    • Có thể xử lý bằng cách tạo symbolic link
  • Trên Linux, vẫn còn bất tiện là phải thêm thủ công đường dẫn <swift/bridging>

Các câu hỏi chưa được giải quyết

  • Chưa rõ cách để trong Swift truyền các kiểu view hoặc byte slice của C++ mà không cần copy
  • Swift không thể nhận diện các kiểu riêng như AK::Optional, AK::HashMap tương đương với các kiểu của std::
  • Cách tích hợp garbage collector của Swift với cơ chế quản lý bộ nhớ của Ladybird cũng vẫn chưa được xác định

Vấn đề này vốn là tài liệu ghi chép có hệ thống các trở ngại kỹ thuật cho việc tích hợp Swift 6.0, nhưng sau đó khi đội ngũ Ladybird ngừng áp dụng Swift, issue “Swift 6.0 Blockers” cũng được khép lại.

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-02-20
Ý kiến trên Hacker News

  • Commit gỡ bỏ Swift có kèm thêm một chút giải thích
    Có thông điệp: “Vì trong thời gian dài không có tiến triển nào nên đã từ bỏ việc áp dụng Swift và loại nó khỏi codebase”
    Có thể xem commit liên quan tại đây

    • Bối cảnh chi tiết hơn được tổng hợp trong issue #933

  • Tôi lần đầu dùng Swift vào năm 2021, và sau hơn 10 năm làm với C#/.NET thì thực sự bất ngờ
    Tôi từng nghĩ C# đã phức tạp, nhưng Swift còn là một ngôn ngữ phức tạp hơn nhiều
    Đặc biệt khi xây backend API hay tầng truy cập dữ liệu thì gần như không có tài liệu để tham khảo
    Kiến thức về Swift chủ yếu tích lũy quanh nền tảng Apple, nên ở các mảng khác gần như có cảm giác phải trở thành người khai phá

    • Trong vài năm gần đây, các ngôn ngữ đơn giản như Python hay Go đã củng cố quan điểm rằng “sự phức tạp là điều xấu”, nhưng tôi nghĩ khả năng biểu đạt cao của ngôn ngữ đôi khi lại giúp ích cho bảo trì
      Như Larry Wall từng nói, độ phức tạp của công cụ phải tương xứng với độ phức tạp của vấn đề (nhắc đến Raku)
    • Tôi chuyển từ Objective-C sang Swift khoảng năm 2018, lúc đầu thấy như một cải tiến
      Nhưng các quy tắc như “struct truyền theo giá trị, class truyền theo tham chiếu” lại xung đột với nguyên tắc “duy trì một nguồn chân lý duy nhất”, khiến trải nghiệm phát triển trở nên nhàm chán và chậm chạp
      Tôi không tiến triển được vì các best practice mâu thuẫn nhau của Swift, và cuối cùng nhận ra nhiều lời khuyên thực ra không đáng tin
    • Mỗi lần compile template Vapor trên MacBook M1, tôi còn gặp vấn đề laptop bị quá nhiệt
    • Tôi cũng có trải nghiệm tương tự. Ban đầu cứ tưởng sẽ học nhanh như Rust, nhưng hoàn toàn không phải vậy
      Có quá nhiều cú pháp sugar, và có đến hàng chục cách để làm cùng một việc, nên lúc nào cũng phải tra lại language reference
    • Vậy cuối cùng bạn có quay lại C#/.NET không?

  • Dù là ngôn ngữ nào đi nữa, tôi hy vọng sau này Ladybird sẽ tập trung vào một bản triển khai JavaScript thân thiện với người dùng
    Việc JS bị lạm dụng để theo dõi hoạt động người dùng, chặn dán nội dung hoặc thu thập quá nhiều thông tin thiết bị là một vấn đề
    Nếu trình duyệt báo về các giá trị giả mạo được chuẩn hóa giữa những người dùng giống như Tor thì có lẽ sẽ giúp bảo vệ quyền riêng tư hơn

    • Nhưng cách này có thể bị nhiều website hiểu nhầm là phát hiện bot rồi chặn truy cập
      Cung cấp như một tùy chọn bật/tắt thì ổn, nhưng để mặc định thì có lẽ khó được chấp nhận
    • Cá nhân tôi tuyệt đối không muốn dùng một trình duyệt phớt lờ web standard và tự hoạt động theo kiểu riêng

  • Việc gỡ bỏ Swift khá thú vị. Lý do không được giải thích rõ ràng nên tôi thấy tò mò
    Chỉ cần nó chạy được trên Linux thì sau này tôi sẽ thử

    • Theo tôi thấy thì có vẻ họ đã bỏ cuộc vì xung đột build lặp đi lặp lại
      Swift gặp vấn đề khi không thể import đồng thời nhiều thư viện C++ phiên bản khác nhau, hoặc phát sinh xung đột phiên bản toán tử
      Swift là ngôn ngữ tốt, nhưng có lẽ quá phức tạp để thêm vào một dự án lớn ở giai đoạn sau

  • Tôi thắc mắc vì sao Ladybird lại thử Swift. Tôi nghĩ Rust chẳng phải có khả năng tương tác với C++ tốt hơn sao?
    GC của Swift cũng có vẻ bất lợi cho hiệu năng trình duyệt

    • Andreas Kling từng nhắc trên Twitter rằng giữa “Swift vs Rust” thì Swift hỗ trợ hướng đối tượng và tích hợp với C++ tốt hơn
      Liên kết 1, Liên kết 2
    • Điều này giống với lý do Rust bất tiện trong phát triển game. borrow checker không hợp với các cấu trúc tham chiếu vòng
      Có cách lách qua, nhưng năng suất bị giảm
    • Thực tế Swift có khả năng tương tác khá tốt, như tài liệu C++ interop cho thấy
      Chỉ là có vẻ chừng đó vẫn chưa đủ với Ladybird
    • Andreas Kling từng nói Rust thiếu tính năng hướng đối tượng, nên bất lợi cho phát triển GUI
      Trước đây họ còn tạo ra ngôn ngữ Jakt trong SerenityOS, nhưng có vẻ cuối cùng vẫn quay về C++
    • Tôi nhớ Rust từng bị bác bỏ vì vấn đề với hệ phân cấp DOM hay bài toán OOP
      Có thể xem thảo luận cũ liên quan ở bài này

  • Swift là một ngôn ngữ phụ thuộc vào Apple quá nhiều, nên chuyện này không có gì bất ngờ
    Chỉ cần dùng tốt phần an toàn của C++ là đủ, mà thực tế hầu hết trình duyệt đều được viết bằng C++

    • Nhưng thật ra mọi trình duyệt chỉ đang bị mắc kẹt với C++ mà thôi
      Chromium và Firefox đang dần thay thế bằng các ngôn ngữ an toàn hơn, và viết lại một trình duyệt mới bằng C++ chỉ là lặp lại sai lầm trong quá khứ
      Việc dùng C++ là di sản còn sót lại từ thời KHTML năm 1998
    • Tôi không rõ cụ thể “tập con C++ hiện đại an toàn bộ nhớ” là gì
      Nó có bao gồm các tính năng STL hiện đại như string_view không? Dù vậy thì vẫn còn khá xa mới đạt được an toàn bộ nhớ hoàn toàn
    • Tôi biết Rust do Mozilla phát triển, nhưng không rõ bản thân Mozilla có được viết bằng Rust hay không
    • Dù sao thì Swift cũng khó thắng được C++ ở những vùng cần hiệu năng cao
      Trừ một vài benchmark, trong chương trình thực tế thì gần như lúc nào cũng chậm hơn

  • Thật tiếc khi Swift bị gỡ bỏ. Vậy không biết ngôn ngữ riêng Jakt có lại trở thành ứng viên không

    • Ladybird đã tách khỏi SerenityOS từ trước rồi, và Jakt không phải ngôn ngữ của họ
      Tôi nghĩ khả năng họ đưa vào một ngôn ngữ mới là không cao
    • Cá nhân tôi lo rằng dự án này đang đổi hướng quá thường xuyên
      Một dự án vận hành bằng tài trợ bên ngoài mà như vậy thì về dài hạn có thể khó duy trì
    • Tôi không hiểu vì sao họ không dùng Rust. Hay là do ám ảnh với C++ chăng?

  • Tôi nghĩ Swift rốt cuộc chỉ là ngôn ngữ đồ chơi của Apple
    Apple sẽ không để nó phát triển vượt xa hơn thế

  • UI Mac của Ladybird là một lớp mỏng đặt trên AppKit
    Nó được viết bằng Objective-C++, không phải Swift
    Xem mã nguồn

    • Tôi là người đầu tiên viết phần code đó
      Nó được làm từ thời SerenityOS, rất lâu trước khi có chuyện đưa Swift vào, nên dùng Objective-C++ đơn giản chỉ vì đó là ngôn ngữ tôi quen thuộc

  • Trước đây khi họ nói sẽ chuyển sang Swift, tôi đã chỉ trích điều đó
    Tôi cho rằng thiết kế của Swift lỏng lẻo, tốc độ compile cũng chậm, và khó có khả năng phát triển thành ngôn ngữ hệ thống
    Họ cũng không có chuyên gia, nên tôi nghĩ quyết định lần này là đúng đắn

    • Swift trông có vẻ là mã nguồn mở, nhưng thực tế Apple vẫn nắm toàn bộ quyền quyết định
      Các tính năng như Concurrency hay Swift Testing cũng là những ví dụ được thúc đẩy theo nhu cầu của Apple
      Phần việc cross-platform chủ yếu do các nhóm nhỏ làm riêng
    • Tôi đồng ý Swift có vấn đề, nhưng nói rằng “không có chuyên gia” thì hơi cường điệu
      Ngay cả ngoài Chris Lattner, các lead của Swift cũng đều là những người được cộng đồng C++ công nhận
    • Cốt lõi của Swift không hẳn là bản thân ngôn ngữ mà là ABI tiêu chuẩn
      Sẽ rất hay nếu phía Rust hỗ trợ cả Swift ABI bên cạnh C như một phần của FFI
    • Vậy bạn đề xuất ngôn ngữ nào?
    • Go cũng tương tự à? Tôi muốn biết hiện nay lựa chọn được đồng thuận nhiều nhất là gì