Even _in_ Xcode it's quite horrible. Only supporting the one major version of Swift bundled with Xcode and forcing old projects to upgrade? Horrible.
For example, I reported a bug about CFRunLoopMode, where the original C-based CF used a comparison of pointer address to determine the equality of two run mode names. The original C version actually compared using the identity rather than equality as the commonModes was defined as a static CFStringRef (CONST_STRING_DECL(kCFRunLoopCommonModes, "kCFRunLoopCommonModes")). Of course this is an optimization for speed on Mac but this is, unfortunately, not supported in Swift and its replication of CF, because in Swift it has to be a public static String. As for today you cannot use commonModes in Linux.
I had assumed zealous iPhone devs would want a homogenous environment where the client and server used the same rough codebase and libraries. Kind of like the node.js crowd, which I'm equally inexperienced with.
Feels like Swift afficiciandos aren't quite as good at PR as their base competition.
I'm basically still back in the jQuery, Python/Django, Ruby/Rails, Tomcat/Java/Spring, PHP/Laravel, space. I understand the comparisons and tradeoffs with those. So, perhaps, I'm fairly agnostic about what's "hot" and "popular".
I really have no idea, since I haven’t used it. It is very new though.
> Feels like Swift afficiciandos aren't quite as good at PR as their base competition.
I guess the issue here is that very few people have even heard of using Swift for server-side development.
Building Swift from source is a big pain in the *. I tried to build it on a shabby VPS running CentOS 7, which is not of my choice but because it was discounted. I had to setup 6GB of swap file to avoid OOM, and then found the intermediate files filled up the disk. Why does LLVM needs so much space to build?
So I switched to ninja (cmake -G Ninja). It can use all the cores and not run out of memory.