Swift on FreeBSD Preview

Original Article ↗ Hacker News Discussion ↗

Porting Swift to FreeBSD & LLVM Context

  • Debate on whether FreeBSD should be “easier” than Linux because of macOS’s BSD roots; consensus is that any shared code is very old and doesn’t help much now.
  • Question why FreeBSD is a “second-tier” target in many LLVM-based projects; most attribute this to resources and demand, not LLVM’s technical bias.
  • Some early adopters report that real projects still hit glibc vs libc differences that many dependencies don’t yet handle.

Why Swift on FreeBSD?

  • General agreement that more platforms help shake out hidden assumptions in compilers and runtimes.
  • For Swift developers, FreeBSD support means they can use the same language for backend or tooling as on Apple platforms (and Linux, Windows, Android).
  • Skeptics ask “why not use other languages,” with one answer being: if your Apple-targeted codebase is already in Swift, reuse and developer familiarity matter.

Swift Usage Beyond Apple Platforms

  • Swift is used on Linux (and somewhat on Windows) for server/backend work, often to share code with iOS/macOS apps.
  • Frameworks like Vapor and others exist; several major early server-side frameworks have died, leaving a smaller ecosystem.
  • Some see Swift as more comparable to Rust/Go (compiled, no GC) than to Node/Python, though others argue Swift’s runtime and safety model differ substantially from Rust.

Concurrency, Safety, and Language Design

  • Disagreement on how “memory safe” and “data race safe” Swift really is by default; strict modes are emerging but not universal.
  • Some praise async/await, actors, ARC, and general ergonomics; others find concurrency primitives weak or easy to misuse, with lingering footguns.
  • Criticism that Swift’s type system and keyword count have grown complex, driven in part by SwiftUI needs and “ship it” pressure.

SwiftUI & Cross‑Platform UI

  • Consensus that SwiftUI is tightly bound to Apple frameworks and unlikely to be open-sourced or ported by Apple.
  • Third-party efforts exist (e.g., mapping SwiftUI to other toolkits), but Swift on non-Apple OSes is currently more about backend/CLI than UI.

Tooling, Ecosystem, and Dependencies

  • Some see Swift Package Manager as pleasantly simpler than heavy systems like Gradle, though server-side Swift still lacks ecosystem maturity.
  • Python is required mainly for tests and LLDB integration, not for running compiled Swift code.
  • Desire for better interop with CMake/vcpkg is seen as important for broader adoption.