While I understand that "the pain is real" when having to deal with crashes that take down the entire process, I personally think is a bit too prominently placed here on the pain points for swift on server list.
I'll take a crashing service any day of the week, if the alternative is a runtime with "let's soldier on, it'll be fine YOLO" vibes. I can image the post-mortem forum post would then be "I accidentally updated half a million user data records with unrecoverable garbage" instead of "things were patchy for a while".
And in my experience (as mentioned upthread as well)
a) you need stuff like retrying/queueing/transactions/compensation anyway for robust systems (as things will go wrong anyway), and
b) it is a lot easier to recover from a crash than a "yolo" service doing whatever.
I am not saying things can't or shouldn't be improved (something like in-process isolates would be cool), but it's not exactly a showstopper either way imho.
To me, way bigger hurdles to having Swift shine on the server are still tooling and ecosystem. I am thinking about things like
- swiftly being still in its infancy
- SwiftPM just barely holding it together at times
- unresolved SwiftSyntax situation
- Foundation/FoundationEssentials and their platform story (despite truly heroic efforts)
- URLSession vs. AsyncHTTPClient, Data vs. ByteBuffer, "how to files?"
- rather underwhelming guidance on "how to deploy" or even "which build settings do I need"
- confusion around XCode... (with its own toolchain, and its own build system, and its own everything...)
- ecosystem struggling to keep up with rapid evolution (concurrency, ownership, macros, ...)
I don't want to come across as too negative, you CAN get it all working - and "Swift - The Language" is well worth it for me. I just wish the tooling (and core package ecosystem) could catch up and keep up with the fast-moving train that is Swift.