I'll offer a different view than most people here.
We're running Swift on the server and I wish we didn't.
Now, as anyone here knows, Swift is a modern language and has a number of big advantages over something more traditional like e.g. Java or Ruby: operator overloading, null- and (reasonably) memory-safe, expressive type system (it has holes, but far fewer than many traditional languages), good support for functional constructs. The language has some warts, but which language doesn't?
But it also has some serious drawbacks:
- The community is extremely small. You won't find libraries for a lot of things. If you find them, there's no guarantee they're supported on Linux; even if they are, they might not have a SPM manifesto, or it might not be up to date for Swift 5.
- There are still serious unresolved compiler bugs for Swift on Linux (like compilation taking an excessive amount of memory) or things where Linux behaves differently than macOS
- There is no good solution for fault recovery when your program crashes; this works fine for apps but for a server application it's less than ideal
- The tooling situation is bad; XCode is almost the only IDE that has full support (there is CLion, it's better in some respects and worse in others), the testing framework is very underpowered and the LinuxMain situation is also an issue, SPM doesn't have an awful lot of features and some serious rough edges compared to more popular tools like bundler, gradle, etc., there are few static analysis tools for Swift (like code climate, or tools to check dependencies for vulnerabilities, etc.), etc. Also, updating Swift versions on a mac is horrible in the way it's almost completely tied to XCode (yes, you can use swiftenv, but it's not obvious how to integrate that well with IDEs). Also stuff like NewRelic etc. obviously has much better integration for more common languages.
- relatedly, there is no common build tool; SPM is not enough for more complicated tasks, so you have to use some other tool, like Make, and those tools obviously don't know anything about Swift, so they're much harder to set up
- there is not a good answer to modularity concerns for big apps. Splitting up code into modules is both too broad (I would like more fine-grained control about who gets to see what, and also things like qualified imports, imports with renaming - if you have two packages that export the same type - etc.) and it also can incur runtime overhead
- also, on big projects, the compiler is slow
and so on. I think Swift on the server is just not there yet. Generally it works, yes, but there's just too many pieces missing.