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.
The set of libraries and supported OSes is a tiny dot comparable with the Go and Rust.
And they aren't even the most relevant for enterprise servers, Java, .NET, C++ are.
If we start listing the kind of libraries used in distributed applications, database backends, Swift has hardly none of them.
IBM is the only major company playing with Swift on the server and it remains to be seen for how long.
Unfortunately i don't see a lot of progress being made on that front since Chris lattner wrote its concurrency manifesto.
For instance, if you download the Swift 4.1 tarball, uncompress it, and start up the REPL, it doesn't really work. The first thing you will do is probably "import Foundation" (because the Swift standard library is really minimal, so Foundation is where most of the interesting stuff is). Then the REPL will complain:
error: repl.swift:1:8: error: missing required module 'CoreFoundation'
sudo chmod a+r /opt/swift/usr/lib/swift/CoreFoundation/*
There are a bunch of little issues like this, that make it clear that Linux isn't yet a first-class platform for Swift. All this stuff is gonna work fine on your Mac.
OTOH though, the Foundation library itself has made amazing, amazing progress. It's super useful, mostly finished, and its pretty clear when stuff that works on Apple platforms isn't yet ready on Linux (because those bits use NSUnimplemented() which just crashes the program). That's important because without Foundation, which contains a lot of the basic building blocks for programs, Swift won't be competing with Go or Rust.
Swift Package Manager is also fully cross-platform and awesome.
Apple also recently released an interesting low-level cross-platform asynchronous event-driven network application framework, called swift-nio. This is super-interesting, but also causes more churn; for instance, once swift-nio was released, the team behind the most popular Swift web application framework, Vapor, started frantically rewriting their v3 release to leverage it.
So... yeah, I would say "server side Swift" is becoming less niche, but... it's still pretty niche. On Linux, it's far less mature than Go or Rust, and you need to expect to have to bing a bunch of annoying little issues to get things working.
: just joking! haha ;-D
Server-side Swift doesn't suffer from these problems, IMHO, but admittedly its Linux support is still a bit questionable, whereas Rust's Linux support is obviously superb. Swift on Linux probably works the best if you're able to use the officially supported LTS distribution, which currently is Ubuntu 16.04.
These answers will vary wildly from person to person, but for a lot of people the answers to those questions will definitely provide a "good reason to move away from Ruby on Rails, Django, Node, etc."
You get similar syntax to Swift whilst leveraging the best server side libraries available on any platform.
I’d rather use just about anything else. If I could use C# everywhere, I would because Microsoft really knows how to cater to developers like no other company and their tools are second to none in many cases.
Compare that to go ( which still has npe) or rust ( whose borrow system appears to be a real pain point) and i think it has an edge.
OS companies care about their own developers, getting their own languages used outside of their eco-systems, only when it matters to their bottom line.
To have sample code for every new feature, etc. This should not be a coop or someone doing it in hindsight - the number of hours people spend re-inventing how to do infinite scrolling tableviews (one simple example) is sad - every new developer has to re-invent the wheel it seems.
This leads to people using third party libraries for things that need no libraries at all, and then before you know it, you're swimming in cocoapod soup, every time you join a new project, and the soup is 50% new ingredients every other time too!
I’m pretty sure they have multiple people with a role like this (I know they have one at least, since I’ve met him).
Nothing should break?
I’d argue the second option is almost universally better.
The last two years or so have been fine for me.
Steve Troughton-Smith, Michael Lauer, Dan Leivers, Peter Molnar, Todd Thomas, Ian McDowell, Simon Wolf, Marco Arment all didn't seem (2017-10-04) in a particular hurry to adopt Swift. 
The following quote from Steve Troughton-Smith in the article that I linked was enough for me - I'm not going to beta test Swift for Apple either.
>I'm not yet convinced of Apple's level of participation in the language — four years on, Swift is not used for important pieces of iOS, OS or frameworks (I maintain a running list of Swift apps from Apple on Twitter, and macOS is definitely less shy about adopting it for new features than iOS). I understand why that is the case (ABI stability, etc), but if Apple's not using it for everything I don't see why I need to be beta-testing on their behalf. I lose nothing from waiting until Swift is 'ready', and I gain all the benefits of Objective-C in the meantime.
$ otool -L `which launchd`
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libauditd.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libbsm.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libdz.dylib (compatibility version 1.0.0, current version 110.50.29)
I guess we can go through the videos to track down where it was communicated.
You might want to check the username on that comment ;)
Linux is second class citizen as far as Swift is concerned for sure. I had to jump through a few hoops to make sure my library works on both Linux and iOS.
Just tried v4.1 and everything compiled cleanly:
BSD licensed code, 100% written in Swift (I went through the trouble of writing the compression code in Swift since the compression classes were missing from the Linux distribution and some older versions of iOS ) - give it a try.
They also want to locally evaluate the equivalent of such #if expressions (in contrast, in C, #if X requires preprocessing the file. That can mean reading dozens of header files, and is dependent on compiler flags)
I think this is a pragmatic way to accomplish that. It restricts you to conditions that Apple has deemed useful, but makes it easier to write good tooling.
I hope though that the way the targetEnvironment condition is implemented is that the 'simulator' exists only in the iOS library.