Swift là Rust tiện hơn (2023)

• Rust và Swift đều chia sẻ hệ thống kiểu mạnh mẽ và các đặc trưng của ngôn ngữ hàm, đồng thời có thể biên dịch sang mã máy native và WASM thông qua trình biên dịch dựa trên LLVM
• Rust khởi đầu là ngôn ngữ hệ thống cấp thấp rồi bổ sung các tính năng cấp cao, còn Swift khởi đầu là ngôn ngữ cấp cao rồi cho phép tiếp cận cấp thấp
• Swift lấy kiểu giá trị và Copy-on-Write làm mặc định, đồng thời hiện thực các khái niệm tương tự mô hình ownership của Rust bằng cú pháp đơn giản hơn
• Ở các phần như kiểu optional, xử lý lỗi, enum đệ quy, Swift bọc các khái niệm của Rust trong cú pháp quen thuộc kiểu C, mang lại mức độ tiện dụng cao hơn cho lập trình viên
• Swift đang phát triển thành ngôn ngữ đa nền tảng và có thể dùng trên Windows, Linux và môi trường embedded, qua đó nổi lên như một lựa chọn thay thế cho Rust

---

Điểm giống và khác nhau giữa Rust và Swift

• Cả hai ngôn ngữ đều bao gồm các đặc trưng của ngôn ngữ hàm (tagged enum, biểu thức match/switch, generic, hàm hạng nhất)
  • Rust cung cấp reference counting và kiểm soát sao chép thông qua Rc, Arc, Cow
  • Swift về cơ bản dùng kiểu giá trị và Copy-on-Write, đồng thời khi cần vẫn hỗ trợ di chuyển ownership (move) và truy cập con trỏ unsafe
• Cả hai đều dùng trình biên dịch dựa trên LLVM để biên dịch sang mã native và WASM

Mô hình bộ nhớ: Rust đi từ dưới lên trên, Swift đi từ trên xuống dưới

• Rust bắt đầu là ngôn ngữ hệ thống cấp thấp rồi cung cấp các tính năng cấp cao
• Swift bắt đầu là ngôn ngữ cấp cao rồi cho phép truy cập cấp thấp khi cần
• Mô hình bộ nhớ mặc định của Swift là kiểu giá trị Copy-on-Write, tương tự Cow<> của Rust
  • Rust nhanh theo mặc định, nhưng khi dùng thì phải xử lý Cow<> một cách tường minh
  • Swift đơn giản theo mặc định, và có thể chọn move thay vì sao chép

Cách tiếp cận cú pháp của Swift: che giấu các khái niệm của Rust theo phong cách C

• Câu lệnh switch của Swift thực chất thực hiện chức năng gần như biểu thức match của Rust
  • Hỗ trợ pattern matching và không có fallthrough
• enum của Swift có thể chứa trực tiếp method, nên có thể được dùng theo hướng đối tượng nhiều hơn Rust
• Kiểu optional (T?) là cùng một khái niệm với Option<T> của Rust, và nil tương ứng với None
  • Trong Swift có thể unwrapping an toàn bằng cú pháp if let val
• Xử lý lỗi tương tự kiểu Result của Rust, còn do-catch và try của Swift là cùng một cấu trúc được bọc trong cú pháp quen thuộc hơn

Khác biệt trong cách hoạt động của trình biên dịch

• Trình biên dịch Rust tập trung vào phát hiện vấn đề và cảnh báo, ví dụ khi định nghĩa enum đệ quy thì buộc phải dùng Box<>
• Swift xử lý enum đệ quy chỉ với từ khóa indirect, và trình biên dịch tự động hóa việc quản lý con trỏ nội bộ
• Swift có nhiều xử lý tự động hơn Rust, nên lập trình viên ít phải trực tiếp đụng tới cấu trúc bộ nhớ hơn

Tính thực dụng và khả năng mở rộng của ngôn ngữ Swift

• Swift được thiết kế để thay thế Objective-C, nên là một ngôn ngữ lớn hơn và thực dụng hơn
  • Tích hợp sẵn nhiều tính năng như class/inheritance, async-await, actors, thuộc tính lazy, property wrappers, Result Builders
• Thiết kế “progressive disclosure” khiến càng học sâu thì càng nhiều tính năng được mở ra

Cân bằng giữa tính tiện dụng và hiệu năng

• Swift là ngôn ngữ dễ bắt đầu và có năng suất cao, còn Rust là ngôn ngữ nhanh theo mặc định
  • Rust là “nhanh là mặc định”, Swift là “tiện là mặc định”
• Rust phù hợp với hệ thống, embedded, compiler, browser engine
• Swift phù hợp với UI, server, một số thành phần của hệ điều hành, và phạm vi ứng dụng của hai ngôn ngữ đang dần chồng lấn

Mở rộng đa nền tảng của Swift

• Swift không còn là ngôn ngữ chỉ dành cho Apple nữa
  • Windows: The Browser Company dùng để chia sẻ mã cho trình duyệt Arc
  • Linux: Apple hỗ trợ Swift on Server và tài trợ hội nghị
  • Embedded Swift: được dùng trên các thiết bị nhỏ như Panic Playdate
• Blog chính thức của Swift giới thiệu các dự án Windows, Embedded, Linux(Gnome), Playdate
• Swift cũng đang cải thiện trải nghiệm phát triển ngoài Xcode thông qua extension VSCode, mã nguồn mở LSP

Giới hạn của Swift và vị trí hiện tại

• Thời gian biên dịch chậm, giống như Rust
• Ngôn ngữ đã lớn lên do feature creep, và một số cú pháp vẫn chưa quen thuộc
• Hệ sinh thái package kém trưởng thành hơn Rust
• Tuy nhiên, Swift đã là một ngôn ngữ đa nền tảng với ABI ổn định, automatic reference counting (ARC), khả năng lựa chọn ownership, và package tương thích Linux
• Swift đang định vị себя như một lựa chọn thay thế tiện hơn Rust, tồn tại như một lựa chọn của hiện tại chứ không phải tương lai phải chờ đợi

[GN⁺]

Ý kiến Hacker News

• Tôi đồng ý với phần lớn nội dung, nhưng chính các chi tiết lại cho thấy cốt lõi của vấn đề
  Xcode là một IDE còn thô thường xuyên bị treo trong các dự án lớn khi làm mới package hoặc xử lý nhiều target. Dù muốn sửa cũng không thể vá nhị phân
  Hệ thống build thì Cargo dễ dùng hơn SPM rất nhiều. Hệ thống macro vẫn còn phụ thuộc vào sinh mã bên ngoài
  Có linter và formatter, nhưng chất lượng thấp. Swift có nhiều vách đá hiệu năng, và suy luận kiểu hai chiều khiến nó chậm với các biểu thức phức tạp. Đây là vấn đề đặc biệt rõ ở các trường hợp dùng quan trọng như SwiftUI
  Import bị gắn ở cấp module, nên chỉ thay đổi một file cũng phải biên dịch lại toàn bộ module. Sự phân biệt giữa class và struct cũng gượng gạo vì tính tương thích với ObjC
  Rốt cuộc, Swift có thể là ngôn ngữ dễ hơn Rust, nhưng trong thực tế lại không đem lại cảm giác đó vì hệ thống công cụ còn non nớt

  • Tôi đã làm một ứng dụng SwiftUI nhỏ và việc tìm rò rỉ bộ nhớ quá khó. Phân tích bằng Instruments và vmmap rồi mà mỗi ngày vẫn rò thêm hàng chục MB
    Tôi thấy mô hình bộ nhớ bán tự động của Swift khó xử lý hơn nhiều so với Rust hay Go
  • Nếu không làm ứng dụng iOS/macOS thì có thể bỏ hẳn Xcode và chỉ dùng CLI swift là đã đủ ổn. Nó cũng chạy tốt trên Linux và Windows
  • Swift hỗ trợ LSP, nên cũng có thể phát triển trên VSCode, Zed, Sublime Text, v.v. Nếu không phát triển riêng cho Apple thì Xcode không phải bắt buộc
  • Swift đời cũ từng có lúc chỉ vì một hai dòng dictionary literal mà build mất 30 phút
  • Phần lớn vấn đề tốc độ biên dịch có thể giảm bớt bằng tách package và khai báo kiểu tường minh. SPM hoạt động ổn hơn tôi từng nghĩ

• Có người nói khi biểu diễn cấu trúc cây bằng enum trong Rust thì cần Box, nhưng thực ra Vec đã cung cấp tham chiếu heap rồi nên không cần

  • Tôi khá rành Rust nên bản thân lỗi này không làm tôi bận tâm, nhưng lại khiến tôi lo liệu phần giải thích về Swift có sai tương tự không
    Enum, struct, union, thậm chí cả kiểu nguyên thủy trong Rust đều có thể có method. Ví dụ có thể gọi như 'F'.to_digit(16)
    Ngay cả raw pointer cũng có thể gắn method. Tôi nghĩ đây là một phần trong thiết kế hiện đại của Rust
  • Bài viết lấy enum của Swift làm ví dụ và khen cú pháp đường mật, nhưng thực tế hỗ trợ union type lại yếu, nên nhiều lập trình viên lạm dụng optional thay vì enum
  • Rất dễ nhầm lẫn khác biệt giữa Vec và Box. Vec là một handle có kích thước cố định tại thời điểm biên dịch, còn Box cần khi xử lý unsized type
  • Tôi thử với Rust 1.92 thì thấy vẫn hoạt động tốt mà không cần Box
  • Bản thân Vec<T> là một handle kích thước cố định trỏ tới dữ liệu trên heap, nên không cần Box

• Swift là một ngôn ngữ hay, nhưng ở phía server-side thì sức thuyết phục khá yếu
  Hệ sinh thái nhỏ, và không mang lại lợi ích gì rõ rệt so với Go hay Rust. Hỗ trợ VSCode cũng chưa tốt, còn Xcode thì tôi không muốn dùng
  Mảng phát triển server đã có Python, TypeScript, Go và Rust chiếm lĩnh. Hệ sinh thái khép kín của Apple cũng là một gánh nặng

  • Tôi thực sự đã từng làm backend bằng Swift với tích hợp trực tiếp thư viện C. Nó chạy tốt mà không cần FFI và hiệu năng cũng ổn
    Tôi thấy chất lượng IDE tốt hơn nhiều ngôn ngữ khác, còn nếu là lập trình hệ thống thì Rust phù hợp hơn
  • Tôi từng làm dự án cá nhân với Swift Vapor, nhưng thấy tốc độ biên dịch và test chậm hơn Go nên khá tiếc

• Swift giờ được gọi là ngôn ngữ đa nền tảng, nhưng trên Linux thì hệ sinh thái vẫn xoay quanh Apple
  Tài liệu, tutorial và thư viện đều được viết với macOS làm chuẩn. Tôi tự hỏi có thực sự nhiều người dùng Swift mà không có thiết bị Apple không

  • Tài liệu của Apple không nêu rõ các giới hạn trên Linux nên tôi đã phải mò mẫm rất nhiều
    Tôi có viết blog tổng hợp trải nghiệm khi làm một WebSocket client
    Bản 2023 / Bản 2025
  • Các lập trình viên Apple nói rằng nó vẫn tốt trên Linux, nhưng trên thực tế hệ sinh thái của Rust vượt trội hơn hẳn
  • Tôi từng định chuyển một công cụ CLI cho Mac sang Linux, nhưng dùng LLM để chuyển thành mã Go còn nhanh và dễ hơn
    Hỗ trợ Android cũng thú vị, nhưng tôi thấy Kotlin là đủ rồi
  • Có quá nhiều ví dụ xoay quanh Apple nên phát sinh vấn đề khi cross-compile. Ví dụ, NSHashTable không tồn tại trên các nền tảng ngoài Apple
  • Swift có công cụ swiftly để quản lý phiên bản compiler, tương tự rustup, và LSP cũng hoạt động tốt
    Cá nhân tôi đang quản lý thư viện để hỗ trợ cả Windows. Chưa hoàn hảo, nhưng đang dần tốt lên

• switch của Swift thực chất gần như là một match expression. Chỉ khác cú pháp, còn bản chất là pattern matching

  • Từ góc nhìn của nhà thiết kế ngôn ngữ, đây có vẻ là chiến lược giữ lại cú pháp switch cũ để giảm bối rối cho lập trình viên
    Họ đưa vào ý nghĩa mới thông qua cú pháp quen thuộc để tạo ra quá trình chuyển đổi dần dần
    Cách tiếp cận này dẫn tới một thảo luận thú vị về việc một ngôn ngữ nên theo đuổi mức độ thiết kế mang tính định hướng đến đâu

• Cốt lõi của Rust là zero-cost abstraction. Swift không tuân theo nguyên tắc này
  Nhiều tính năng của Rust được thiết kế để giữ vững quy tắc đó, và mô hình ownership là ví dụ tiêu biểu

  • Mô hình ownership tường minh của Rust giúp ngăn lỗi runtime ngay từ lúc build đối với những vấn đề có thể xảy ra trong actor hay Task của Swift
    Dù có đường cong học tập, nó vẫn giúp nâng cao hiệu quả phát triển
  • Swift cũng hỗ trợ mô hình ownership, nhưng không cưỡng chế mạnh như Rust

• Có nói rằng trình duyệt Arc đã dùng Swift cho Windows, nhưng sau khi ngừng phát triển thì có vẻ các công việc liên quan cũng bị hủy theo

  • Dù vậy, Swift for Windows vẫn tồn tại, với trang cài đặt chính thức và Windows Workgroup vẫn đang hoạt động

• Lý do tôi thích Rust là vì nó không bị phụ thuộc vào một tập đoàn lớn. Tôi nghĩ Apple hoàn toàn có thể bỏ Swift

  • Nhưng khả năng Apple bỏ Swift là thấp. Rust thậm chí còn có thể rủi ro hơn vì phụ thuộc cộng đồng nhiều hơn
  • Phần lớn phần mềm của Apple được viết bằng Swift nên họ không có lý do gì để từ bỏ nó
  • Go cũng gắn với Google, C# cũng gắn với Microsoft. Swift cũng là mã nguồn mở nên khó phê phán theo logic đó
  • Swift do Apple tạo ra, nhưng được cộng đồng mã nguồn mở duy trì
    Điều này cũng được nêu rõ trong bài wiki

• Nếu tận dụng tính năng reference counting của Rust thì có thể đạt được sự tiện lợi mà không cần chuyển sang Swift
  Có thể dùng Rc cho tham chiếu chia sẻ bất biến, và dùng interior mutability để triển khai thay đổi dựa trên kiểm tra runtime
  Tài liệu Rc, Tài liệu về interior mutability

  • Trong môi trường đơn luồng thì dùng Rc, còn đa luồng thì dùng Arc. Nhờ trait Send nên sẽ không có chuyện dùng nhầm Rc ở sai thread
  • Tuy vậy, nhược điểm là mã trở nên quá dài dòng

• Tôi đã làm công cụ phân tích và compiler cho Linux bằng cả Swift lẫn Rust
  Swift khiến việc quản lý bộ nhớ thuận tiện nhờ ARC, còn Rust đòi hỏi suy nghĩ nhiều hơn nhưng chất lượng tooling lại tốt hơn hẳn
  Clippy và hỗ trợ LSP rất tuyệt, còn Swift có nhiều tính năng dựng sẵn
  Tuy nhiên, cộng đồng Rust lớn hơn nên dễ tuyển người hơn, và tôi cũng thấy Swift có tiềm năng như một ngôn ngữ thay thế C++