Swift is a more convenient Rust (2023)

Swift vs. Rust: Ergonomics and Philosophy

• Some find Swift more ergonomic: parameter defaults, optionals / null-short-circuiting, and ARC make it feel faster to write and easier to learn than Rust’s borrow checker.
• Others argue Rust’s “zero-cost abstraction” and explicit ownership are fundamental advantages; Swift’s convenience often trades away semantic precision and predictable performance.
• Several Rust-specific points in the article are called out as wrong (e.g., unnecessary Box in a tree enum, implying Rust enums can’t have methods), which makes commenters distrust the Swift comparisons.
• Rust can be made “more convenient” via Rc/Arc and interior mutability, but this is verbose; Swift can adopt an ownership model too, but it’s opt‑in instead of the default.

Type System: Enums, Unions, and Errors

• Swift enums are powerful but often awkward: modeling state via enums + protocols can be boilerplate-heavy, so many codebases fall back to “masses of optionals” rather than clean sum types.
• Some want TypeScript‑style union types (String | Int) for ad-hoc cases; others warn that unions and algebraic sum types behave differently and union semantics are a footgun.
• Rust’s Result/match model vs. Swift’s try/throw is debated: some see Swift’s syntax as “deceptive sugar” over the same idea; others prefer Rust’s explicitness.

Tooling, Build Systems, and Compilation

• Xcode is extremely polarizing: described both as “one of the most powerful IDEs” and “the worst IDE I’ve ever used.” Complaints include sluggishness, crashes, mysterious errors, and poor scaling.
• Many Swift users bypass Xcode altogether, using the swift CLI and LSP in editors like VS Code, Helix, Emacs; LSP quality is considered improving but not flawless.
• Cargo is widely regarded as superior to Swift Package Manager. SPM works for simple projects but becomes painful with C/C++ libs, cross‑platform builds, or xcframework output.
• Swift compile times and type inference (especially with SwiftUI and heavy generics) are a recurring pain point; Rust is not perfect either but is seen as more predictable.

Platform Lock‑In, Ecosystem, and Governance

• A major thread is trust: Swift is perceived as tightly coupled to Apple, which has previously shifted away from Objective‑C. Many fear Swift would wither if Apple’s priorities change.
• Others counter that many languages are corporate‑backed and that Swift is open source, heavily used internally by Apple, and unlikely to be dropped soon.
• Outside Apple platforms (Linux/Windows), experiences are mixed to negative: toolchains exist, but APIs, docs, and libraries are often Apple‑centric, with bugs and missing pieces.
• Server‑side Swift is viewed as niche: some positive reports (e.g., Vapor), but others cite slow builds, inconsistent Foundation on Linux, tiny talent pool, and little to recommend it over Go or Rust.

UI Frameworks and Concurrency

• Swift is appreciated for native Apple UI work, but SwiftUI draws harsh criticism: incomplete, buggy, hard to debug, and poor at scaling beyond small components.
• Memory management via ARC is seen as convenient but brittle: cycles and leaks (especially in SwiftUI and async code) can be hard to diagnose, compared to Rust’s compile‑time guarantees.
• Swift’s async/await and actors are described as historically messy but reportedly improved in recent versions (fewer “actor hops,” better isolation defaults).

Language Choice in Practice

• Many commenters would only choose Swift when targeting Apple platforms exclusively; for cross‑platform GUIs, infra, or systems work, Rust, Go, C#, Kotlin, or JS/TS are preferred.
• Interest in learning Swift exists, but multiple people say the article’s overselling of “Swift as convenient Rust” and technical inaccuracies weaken its case.