yes, in general, i have found Swift’s “crash early and crash violently” philosophy to be problematic for server-side use cases, where availability is paramount and downtime is fatal.
to this day, Swift doesn’t have a good way to recover from precondition failures, so a single logic error in a many hundreds of thousands of lines codebase, triggered by a single unlucky visitor (or robot) has a nuclear-sized blast radius that takes down the service for everyone.
i think the language currently also ships with some unfortunate default settings, which are straightforward for an experienced engineer to correct for, but can bite novice developers badly. i’m not sure what the status of changing these defaults is, but i hope it comes soon because it is the type of incident that can lead business-oriented folks within an organization to conclude that Swift is an unwise choice on the server.
of course you can respond “just hire people who know what they are doing”, but at the business level, having higher skill requirements to accomplish the same high level task is seen as a hindrance, not a virtue.
what we need to emphasize in order to make Swift a truly great server-side language is robustness, the ability for individual parts of an application to fail without causing an entire service to collapse for many end users at once. and it needs to become something “junior” engineers can be trusted with, instead of something you need to recruit an expert server-side sherpa to navigate.