Swift Static Linux SDK
Swift’s new static Linux SDK aims to make Swift binaries easier to distribute across Linux systems, pushing more of the dependency stack into the executable itself. Commenters weigh the trade-offs between static and dynamic linking — from security patching, rebuild costs, and SBOMs to developer convenience and reduced “dependency hell” — and compare Swift’s approach with Rust, Go, and traditional distro packaging models. Alongside this, Swift 6’s broader ambitions emerge: improved concurrency, C++ interop, embedded and WASM targets, and a potential role as a general-purpose, cross‑platform language, even as tooling gaps and a relatively young server-side ecosystem remain concerns.
Static vs dynamic linking and distros
- Big subthread on static linking (Swift static Linux SDK, Rust/Go culture) vs classic distro-managed shared libraries.
- Pro-static side: vendoring dependencies avoids distro-induced version skew, makes builds reproducible, and simplifies distribution (single binary, works across many distros, fewer “dependency hell” issues).
- Pro-dynamic side: distros can patch one shared library to fix many packages at once; rebuilding thousands of statically-linked binaries on a vuln is expensive and often unrealistic.
- Several note that Rust/Go can link dynamically, but tooling and culture strongly push “static everything”; Swift is praised if it allows real choice.
Security, vulnerabilities, and SBOMs
- Critics of static linking highlight past crises (e.g., zlib/xz-like issues): tracking every embedded copy is painful; you often don’t know which version is in a random binary.
- Others argue rebuild storms are acceptable and that binaries should ship an embedded manifest/SBOM of their vendored deps; Go is cited as already doing this.
- Disagreement over whether static linking is a “security nightmare” (opaque dependency graph, slow patch propagation) vs dynamic linking being a risk (uncertain code actually executed at runtime).
Swift on Linux, ABI, and distribution
- Swift binaries on Linux still depend on some system libraries; ABI is explicitly stable only on Apple OSes. On Linux, ABI stability is “unclear” and would likely need distro support.
- New static SDK plus musl-style targets make Swift more competitive with Go for easy container distribution (e.g., Alpine).
- Some see this as aligning with Apple’s broader push: embedded Swift, WASM targets, user-definable platforms.
Language comparisons and ergonomics
- Multiple commenters are enthusiastic about Swift 6: strong type system, no tracing GC (ARC instead), ADTs, protocols (traits), macros, data-race-free concurrency, distributed actors, C++ interop, embedded mode, and upcoming WASM.
- Some describe Swift as “better Go” and “better Rust for app dev,” especially with richer stdlib, async/await, testing, and ergonomics like named arguments and advanced enums.
- Counterpoints: Swift compilation is much slower than Go and often slower than C++ with templates; tooling (SPM configuration, compiler diagnostics, macro setup) has “sharp edges.”
- Others feel the language has become complex and “baby C++”-like, though some argue most developers only need a simple subset.
Ecosystem, server-side, and tooling
- Server-side Swift interest exists (e.g., Vapor), but several say the non-Apple ecosystem is still relatively immature compared to JVM, Go, or Rust.
- Some report painful past experience with server-side Swift (Apple-first design decisions, Linux being second-class), and now prefer Kotlin/Java.
- LSP support for VS Code is described as usable but not yet on par with top-tier ecosystems (missing richer refactors, etc.).
Cross-platform UI and other platforms
- SwiftUI itself is closed-source and Apple-only; third-party SwiftUI-like frameworks (Tokamak, SwiftCrossUI) and wrappers around GTK/Qt/LVGL exist but are seen as not yet mature for serious cross-platform products.
- Embedded Swift and Swift-on-WASM examples are emerging and generate excitement, though they are still early-stage.