There are plenty of good reasons in the discussion already why server-side Swift might be a risky choice. I’ll add one more. I like Swift. I’d like to use it m

There are plenty of good reasons in the discussion already why server-side Swift might be a risky choice. I’ll add one more. I like Swift. I’d like to use it more. Most of my work is either web backend or web frontend or both. My only Swift experience is from developing personal use Mac apps. But I do like the language. [The biggest thing holding me back from even trying out a weekend project with server-side Swift is the fact that the only weekend project server-side work I have in mind is specifically oriented around improving on TypeScript/Node offerings.] But the next reason after that is that Apple just isn’t invested in server platforms generally. This is similar but slightly different from the several comments about Apple not investing in other platforms. Apple only tangentially invests any effort into Windows support to benefit the iOS/macOS platforms, true. But their only motivation to support Linux is gated by the extent to which they might want to focus on server products or cloud platform products in general. They categorically don’t show much interest. Their own networked products use a hodgepodge of whatever was probably most convenient: some AWS, some Azure, some Google Cloud; a huge smattering of languages; some in house stuff, a lot not; a hilarious history of offering server hardware and letting it languish. They want SwiftUI to be the future successor to the Cocoa APIs, and it’s been notoriously undocumented. What pain lies for people trying to use the language for use cases they actually don’t care about?