It's another classic example where it's simply not enough to open source something, you have to really allow and encourage the developers to contribute to increase the adoption.
It's another classic example where it's simply not enough to open source something, you have to really allow and encourage the developers to contribute to increase the adoption.
For instance, maybe it's fixed now, but for years running the Swift REPL on linux would spit out a few error messages every time you ran it. It still worked, but it gave the impression of being poorly supported.
What really killed it for me was the rollout of features like FunctionBuilders (now result builders) and property wrappers. These were just basically crammed into the language in a half-finished state with no community review, to support the requirements for SwiftUI, despite many other features languishing for years and not being implemented due to concerns about how they would affect swift's "design space".
Following that, I had the impression that Swift was and would always be prioritized towards Apple's goals, and any use-case outside of this would be a distant follower.
If I had to guess, they don't do it because:
1. they don't think the resources it would take would represent a good ROI,
2. and/or they think it's good for them that developers who invest in their ecosystem have skills which are not transferrable to other domains