Swift 4.1 Released(swift.org)
swift.org
Swift 4.1 Released
https://swift.org/blog/swift-4-1-released/
81 comments
Is "server side Swift" becoming less niche? I'm not clear on why it isn't competing more with Go and Rust.
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.
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.
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.
[1] https://github.com/apple/swift-nio
[1] https://github.com/apple/swift-nio
There are many. There’s even an “official” one, SwiftNIO, that was released recently.
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".
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".
> Fairly niche, I assume?
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.
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.
Please forgive me for my rant:
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?
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.
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.
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.
> Swift outside of Xcode hasn't been the best of experiences even on macOS.
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.
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.
Xcode 9 supports two major versions and it seems likely that that will continue.
Swift on Linux has access to a substantial portion of Foundation as well as any other C libraries, such as libc.
There are a lot mismatches.
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.
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.
Ahh, yes. That makes sense. No batteries included.
It is not really portable outside Apple eco-system, just like Objective-C ever was.
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.
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.
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.
Unfortunately i don't see a lot of progress being made on that front since Chris lattner wrote its concurrency manifesto.
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:
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.
[1]: https://bugs.swift.org/browse/SR-2783
[2]: https://bugs.swift.org/browse/SR-7065
[3]: https://github.com/apple/swift-corelibs-foundation/blob/mast...
[4]: https://github.com/apple/swift-nio
[5]: https://vapor.codes
[6]: just joking! haha ;-D
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[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.
[1]: https://bugs.swift.org/browse/SR-2783
[2]: https://bugs.swift.org/browse/SR-7065
[3]: https://github.com/apple/swift-corelibs-foundation/blob/mast...
[4]: https://github.com/apple/swift-nio
[5]: https://vapor.codes
[6]: just joking! haha ;-D
Wow, super detailed. I never get anything this detailed or informative on any other type of forum. Appreciate it.
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.
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.
[deleted]
[deleted]
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.
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.
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.
But if you wanted a comprehensive type system then why not Scala.
You get similar syntax to Swift whilst leveraging the best server side libraries available on any platform.
You get similar syntax to Swift whilst leveraging the best server side libraries available on any platform.
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.
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.
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.
Have you tried crystal? It has much of the same in how its union types work.
Performance-wise server-side Swift is miles ahead of Node and Django. Apart from that, the tooling is indeed terrible...
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.
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.
RE: Server side Swift
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:
http://pdfjet.com/swift/PDFjet-Swift-2018-03-30.zip
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.
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:
http://pdfjet.com/swift/PDFjet-Swift-2018-03-30.zip
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.
[deleted]
I don't quite understand why they are putting specifics like detecting the iOS simulator in the core language.
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.
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.
Probably because "how do I detect simulator" is one of the most asked questions about swift. So Apple uses the leverage they have over the language.
I hope though that the way the targetEnvironment condition is implemented is that the 'simulator' exists only in the iOS library.
I hope though that the way the targetEnvironment condition is implemented is that the 'simulator' exists only in the iOS library.
Because in the context of conditional compilation it is just yet another target.
I don't know if anyone who can edit the blog is reading this, but the link to "SE-0186 Remove ownership keyword support in protocols" is wrong, it should point to https://github.com/apple/swift-evolution/blob/master/proposa...
Thanks for the heads up. It should be taken care of now.
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!
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!
> a dedicated sample code person who's well versed in Swift, to make the sample code consistent and well documented
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).
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).
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.
> Swift 4.1 is a minor language release. It is source compatible with Swift 4.0.
Nothing should break?
Nothing should break?
A lot of sample code is still Swift 1 or 2 code, which is not source compatible.
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.
You have two choices: bake the language fully before release, or push out what you have and get the community involved.
I’d argue the second option is almost universally better.
I’d argue the second option is almost universally better.
Reasoning about effect aside, I walked away from an iOS project (personal) primarily because the language moved so fast it lot me.
Swift changed less between 3 and 4 than between 1.0 and 1.1.
The last two years or so have been fine for me.
The last two years or so have been fine for me.
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.
You could do it Objective-C.
I don't think you're the only one.
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]
https://www.hackingwithswift.com/articles/27/why-many-develo...
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]
https://www.hackingwithswift.com/articles/27/why-many-develo...
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.
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.
launchd is also written in Swift now.
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)That was part of the message at WWDC 2017, Dock and launchd ported to Swift.
I guess we can go through the videos to track down where it was communicated.
I guess we can go through the videos to track down where it was communicated.
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.
Unfortunately, if what others here are stating is true, many of the examples date to Switch version 1 and 2...
Getting it out to be used by as many devs as possible is also a valid way of "nailing gown".
Go to the Apple developer page of sample code https://developer.apple.com/library/content/navigation/#sect... and see how much actually compiles, its not a lot.
I saw a couple regressions, but I believe that was the goal
I’ve got a couple dozen small Swift 4 examples on Github for anyone looking for sample code:
https://github.com/melling/ios_topics/blob/master/README.md
https://github.com/melling/ios_topics/blob/master/README.md