@doctorj I hope I’m not too late, but you know holidays. I’ve been running several Swift on the server components and here are my top 4:
-
Build times, compute and memory footprint during build are astronomical. Swift components are costing us 3x more than JVM/Kotlin components and 10x more than Rust/Go components to build. It’s really quite expensive to run Swift on the server.
-
Limited supported platforms e.g. what about Debian or BSD or Fedora etc. It’s also misleading that development and production platforms are not the same. Creating custom Docker images is not easy with dependencies, build times, and the resulting image sizes are gigantic - we actually pay for storage and egress for our container repositories.
-
Developing for the server on macOS is a huge pain in two main areas: 1) the overlapping types with iOS/macOS frameworks (e.g. Crypto) makes it impossible to know if what builds on macOS will build and even run on some Linux environment. Others have already mentioned the pain of FoundationEssentials, networking etc. 2) As a result of the previous, the ecosystem of Swift packages is full of libraries which although claiming support for server/linux targets, do not actually (correctly) support that.
-
DX around tooling has many papercuts (we see this when onboarding devs coming from more established server language ecosystems). One very prominent point is, well, IDE - Xcode is great for apps but positively hostile for server apps. There is VSCode but beyond that it’s hard to configure proper language server support (e.g. say one is using Zed, or vim/emacs inspired setup), get hints about supported targets for specific functions, running tests, visualising test results in existing systems, integrating with vulnerability/security scanning tools etc.