Swift Static Linux SDK

Original Article ↗ Hacker News Discussion ↗

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.