My impression has been that Swift is still very much seen as an “Apple” language, rather than a cross platform one. Another issue is that there are some operations that lead to crashes if they detect illegal behavior, in the name of providing safety and consistency. Some feel that this kind of behavior is counterproductive in a server environment because it would lead to the server keeling over if something goes wrong.
Tooling outside of Mac I imagine is lacking as well. I also asume libraries outside of Mac too? Strong standard libraries make languages easier to adopt. Go had a web server out of the box removing the whole "which web library do I use?" element out of the equation.
Swift outside of Xcode hasn't been the best of experiences even on macOS. Swift Package Manager works well from the CLI(although the Rust compiler's error messages have spoiled me), but using other editors usually requires some sort of sacrifice. A lot of them have inconsistent code completion if any at all, or no debugging or inline error messages. It's not bad for working with small Swift scripts, but working on a bigger project without those tools isn't great.
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.
Unfortunately Apple still considers (Core)Foundation to be outside the auspices of Swift Evolution, which makes getting issues like these fixed much harder.
Interesting. I'm surprised not have seen more user contributed libraries for server side Swift that work around this, and the (mentioned below) lack of libraries, like ready made web server implementations. I viewed the apple fan club as more ambitious in the past. To be fair, I have zero experience in the Mac/iPhone area.
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.
Apple working on an HTTP server library called swift-nio-http2 [1] that they say is "coming soon", so I would wait for that before using swift on the server side.
Ahh, okay. Fairly niche, I assume? I'm pretty religious about following HN and other tech news feeds, but have never heard of "Swift NIO". While, on the other hand, I've heard tons about node.js and Golang developments, even though I'm equally inexperienced with those.
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".
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?
In my experience building LLVM (not for Swift though), it depends on your make -j switch. With -j 16 I would run out of memory quickly (32 GB RAM, 16 GB swap), with -j 1 it would be quite conservative memory-wise, but take hours to build.
So I switched to ninja (cmake -G Ninja). It can use all the cores and not run out of memory.
I actually had to build LLVM last week, so I feel your pain. I ran it on my Mac, thankfully, but I accidentally built in debug mode and ended up a 25 GB build folder. Turning on release mode and -Os brought it down to two or three gigabytes.
After installing Xcode and stuff, on my MacBook Pro, there is usually less than 10GB free space. I have to delete and purge up and down till ~14GB for sure every time Xcode gets updated.
If you’re looking to clean some space, I recommend checking out ~/Library/Developer/Xcode. Among other things, Xcode stores device symbols for every iOS device you’ve ever connected to your Mac here. You might be able to clean out a couple gigabytes.
I think server side Kotlin will steal all the thunder from Swift. It's very similar in style, but JVM stack makes it more versatile, IntelliJ tooling is leaps ahead, and the language seems to a bit more smarter designed overall.
I’m with you on the prediction, but I disagree with your last point. My impression of Kotlin (as an avid swift user) is it is a modern, well-designed Java, but it’s still Java. What Swift does differently is what really sells me on it in the first place: copy on write and deterministic (for the most part) ARC.
ARC an be a real pain with closures though. I'm often discouraged to use them in Swift, because I can't be bothered to figure out if I have all my references correctly set. GC lets you not worry about it. It comes with its own disadvantages, but does it really matter in most cases? Optimizing for productivity seems way more important then pure performance these days.
Well, the gotcha's are pretty straight forward - don't capture self. Xcode actually features runtime memory leak detection which can detect this (though I've never seen it actually work...).
My personnal reason for not moving to swift is concurrency. As long as there isn't a clear prefered model for concurrency (node-style event loop with asyncs or actors), i won't start developing on the server with this language (which is great).
Unfortunately i don't see a lot of progress being made on that front since Chris lattner wrote its concurrency manifesto.
If you follow the trend - the language never becomes really popular (generally) unless the most popular platform (even among developers) - Windows - is fully supported. Go never really took off until this happened.
Swift on Linux, which is the key to "server side" swift, is really coming along. However, it still has several rough edges that, while they can be worked around, mar the experience and probably discourage a lot of casual tinkerers who try it.
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:
Then, say you make a toy program, and try to debug it using lldb. That might seem to work, but as soon as you stop at a breakpoint and try to print a value, booom! lldb will spit a wall of error text at you. (This assumes your program imports Foundation, again, but almost every program will.) This is also work-aroundable, as long as you are able to find the JIRA ticket thread describing how to work around it[2].
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[3], 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[4]. 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[5], 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[6] a bunch of annoying little issues to get things working.
I'm not yet sure if "server-side Rust" is actually viable. Some of the language concepts are too complicated, and the obvious benefits (no need for GC and better control for concurrency) don't seem to apply to many server-side things.
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.
There is no good reason to move away from Ruby on Rails, Django, Node, etc.
I'd argue that now that Typescript is gaining momentum - I'd say there's a good case for Javascript (Node.js) solidifying itself as the leader for anything but apps that are performance critical.
Well, you are overlooking the language itself: how nice is it to code in, does it help you iterate more quickly, and how much does the awesome type system help you prevent errors, refactor code more easily, and promote stability over time?
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."
I agree with you that the advent TypeScript is strengthening JavaScript's position immensely. TypeScript is really awesome. But it is still a type system bolted onto JavaScript, and it being a strict superset of JavaScript — even though that was a great design decision on balance — means it just can't do as much for the programmer as Swift can in that regard.
I learned enough Swift to know that I think it’s terrible and that I really don’t like the way that Apple designs anything. They couldn’t get strings right the first time because they were too pedantic about how I should think about them, they prefer all sorts of weird shortcuts that make code unreadable, like trailing closures, if-let and some other things I can’t remember and the tooling is clunky, slow and generally sub-par to my preference. I think Xcode and Mac OS are the worst and I’d probably kill myself if I had to actually code with them instead of just using them to compile stuff like I do now with my React Native projects.
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.
on the other hand , if let and guard let , together with optional, is what makes swift the safest language i've ever developped with relative to null pointers exception (I haven't had any in years) yet bringing almost no syntax overhead.
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.
Apple to me is not a software / services company. They failed to make Swift popular and imho it will just artificially keep Swift alive while everyone else will be using RN,Xamarin and similar.
Swift is popular on their platforms, just like .NET used to be popular only on Windows, or even Java used to run better on Solaris back in the day.
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.
It would be helpful if Apple did a review of the sample code in the developer's library and fix all the software that won't even compile anymore. It doesn't help people trying to learn this language if the sample code won't work.
+1 I'd also make a humble suggestion to have a dedicated sample code person who's well versed in Swift, to make the sample code consistent and well documented.
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!
Yeah, Apple's developer documentation is definitely subpar. They don't maintain the samples well (if there are any) and they are a bit on the lazy side when it comes to documenting class methods and variables. Sometimes they just tell you that something exists.
Am I the only one who finds the rapid source incompatibilities problematic? Like maybe a language shouldn’t move so fast or be better nailed down before production.
I would say that a lot of people jumped on board with Swift before it should really have been used so widely. Objective C was - and still is! - a totally acceptable way to build an app for iOS.
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. [0]
I feel most of the developers there more more unhappy about the lack of ABI stability, poor tooling, and learning a new language than the constant changes that Swift has.
Fair point, that's more precise. You're clearly better informed than me.
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.
Apple has actually gotten quite good at adopting Swift for new projects where ABI stability is not an issue. Off the top of my head, Picture-in-Picture, Dock, and Touch Bar on macOS, and Calculator and parts of the WWDC app on iOS are mostly Swift. New developer tools, such as Playgrounds and parts of Xcode are Swift as well. Of course, you’ll notice that none of the uses I mentioned were core frameworks, since these are places where Apple cannot use Swift code.
Huh, I wasn't aware of that. Are you sure? launchd doesn't seem to link against any Swift libraries:
$ otool -L `which launchd`
/sbin/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)
Like another commenter has mentioned, Swift is now almost nearly source compatible. The compiler already provides support for any version of Swift back to version 3.2.
LOL. I was actually referring to your specifics and protomyth's general statements about much of it not compiling, but it's obvious you are familiar with whatever the situation is. :)
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.
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 want functionality that is similar to the C preprocessor’s #if, but different in that they want to require both branches to syntax check.
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.
