Current state of the Swift ecosystem with regards to promises isn’t much better than the callback hell. There are multiple implementations, none of which are considered for inclusion in the standard library. None of these libraries are compatible with each other, and even worse, I see a lot of 3rd-party libraries shipping their own promise implementations as well, that’s in addition to each one having their own Result type implementation.
Of these libraries the fastest are Google Promises and BrightFutures, but only the latter can be used on Linux (untested though).
I honestly think that deferring or ignoring this issue hurts adoption of Swift significantly. When picking a language for server-side, ease of use and availability of libraries matters more than being able to write frontend and backend code in the same language.
Significant amount of server-side libraries written Swift would benefit from first-class concurrency support, but they aren’t being written or not as good as they could be.
If this is fixed only with Swift 10 (i.e. in 5+ years), that would be too late. Consider that a lot of foundational server-side software in recent years have been written in Go (Docker, Kubernetes, CockroachDB etc) and even more would be written during those 5+ years. It could have been written in Swift if there was more focus on concurrency and Linux support.
I hope we as a community could fix this if we look at what low-hanging fruits are there. The proposal is ready and there is a Swift compiler patch from @Chris_Lattner3 (https://github.com/apple/swift/pull/11501), I would be happy to know what else is needed to get things going.