Great language-level features (especially the concrete extensions, finally), but I'm most interested in whether the compiler still crashes, whether it can correctly report error messages in code using type inference and closures, and whether incremental compilation works properly.
Yeah I agree. I've been using Swift for about 2 years, and my major issue is the tooling (Xcode, CocoaPods, etc.).
I've been trying plugins for every editor I like (emacs, sublime text, VS Code), and all the code completion sucks. I've researched it a bit, and it all appears to be issues with SourceKit itself. I think Swift would do much better on Linux with proper tooling - when I look at Go and Rust tools everything seems to work (I've never tried them - just going off the project readme.md and videos). I wish this was a bigger priority, but it doesn't appear to be.
It seems like this will all probably get better when the Swift Package Manager supports iOS/tvOS/watchOS. Most completion tools don't parse the Xcode project for frameworks, so you don't get completions outside of UIKit/Foundation and what's declared in your file. I imagine when SPM is ready it'll make it much easier to parse dependencies and include completions for them.
CocoaPods isn't an official tool so it's not really the Swift team's fault that it's bad. SPM should certainly have been "done" by now though, Carthage was put together quicker by a team of volunteers without access to Apple's resources and generally works perfectly (yes, deferring most of the work to xcodebuild).
For me, the amount of pleasure I derive from using Swift instead of Objective-C far outweighs the downside of crashes and bad error messages. At this point I think I'd stop working on iOS/macOS if I had to go back to working in Objective-C again. Though I do hope they make fixing the compiler crashes a priority soon.
We fixed a lot of bugs while working on the new generics features in Swift 3.1 (and also recursive protocol constraints, which didn't quite make it in but a lot of the plumbing was done for it).
For example, in practicalswift's fuzzer collection, 260 cases were fixed between 3.0 and 3.1, for a total of 5426 fixed (with 39 still open).
The original statement regarding Swift 4 was "the primary goals are to deliver on the promise of source stability from 3.0 on, and to provide ABI stability for the standard library." I hope this statement is still true. The Swift 3 upgrade was painful, I hope to see more stability out of the language from here on out.
It was a bit of work but I would say that it was worth all the changes. I like Apple's preference to make breaking changes to make the language better.
Apple wrote a decent conversion tool for 2.x -> 3.x; yes it is far from perfect.
Btw, I documented most of my changes on my blog, in the hopes that the next person would be able to make their changes in half the time:
Everyone using Swift will soon be on version 3.x. Compare this to languages like Python where there will need to be a major 2020 conversion to 3.x because many developers are dragging their feet.
The community needs to accept a little pain or pay for past language design mistakes for decades.
> Compare this to languages like Python where there will need to be a major 2020 conversion to 3.x because many developers are dragging their feet.
That's not a very fair comparison. Python is 25 years old and this migration is being requested after 20 years in existence. There is no way a successful language can perform this kind of migration at that age without pain. Swift will be no exception if it's still around and popular in 20 years.
Yes, I understand that the conversion is in some ways more difficult because there's a larger legacy code base. However, the conversion has already been extended 5 years:
Really? I've been programming for almost 35 years and I can't think of many languages that made such big changes. Java, for example, is still compatible with 1.0.
Yes, I know that. You could provide your examples of some other popular languages that we all know about. Sure, it's easy to change a language no one uses, but when you've got hundreds of thousands of users, it's much harder.
pain(x) = Language upgrade pain after x years of development. That seems like a somewhat objective concept -- about which it is fairly hard to make guesses ... If I _had_ to guess though, because of the static type system and the process guiding swift's evolution, I would hazard that Swift 23 -> Swift 24 will be significantly easier than python 2 -> python 3 ...
> Xcode 8.3 drops support for Swift 2.3. So, if you were holding back on your migration to Swift 3.x, now is the time to make the switch!
Python 2.x keeps working pretty well for many large backend-service codebases that need a lot of stability.
Swift 2.x is used for iOS and macOS client/UI apps that get significant UI "enhancements" every year. The stability desire is much less, in every sense.
Concrete constrained extensions and nested generics are great. These were pretty big holes in the previous versions, and will help simplify a bunch of real code.
They should finish the free Foundation implementation[1] already which is the true standard library. Swift is not very useful without it, and they're talking about 4.0. It seems like Apple's giving their minimum to the community
I have always considered this a weird effort. Foundation is not Swifty (delegate protocols with optional methods, etc.). Why do we need a Swift implementation of NSMutableArray or NSNumber? Just use Array or Int/Double!
Of course, a core Swift library for URL handling is important! And on macOS/iOS it can be implemented on top of Foundation. But I don't think that library should come with a bunch of geometry, collections, or number formatting types as well. µframeworks are Swifty. The SPM documentation says something like "in general more modules is better than fewer modules", so it's weird to have a giant framework as an official core library.
For networking, Kitura uses Kitura-net, which uses BlueSocket, which in turn uses C library's sockets[1]. On GNU/Linux, this is the GNU C Library, for which a package (Glibc) is provided by the Swift port[2].
For asynchrony they seem to be using libdispatch despite it being "early in the development"[3], but I've also noticed they're wrapping epoll and curl (see 1.B again), so it's hard to gauge the real extent of the hack.
The most recent episode
of the podcast ATP has Chris Lattner discussing why trade offs such as this where made and how they prioritised. It's worth a listen. He really is/was a great ambassador for the language.
I'd say it's far better strategically to make sure swift on iOS is the official mainstream way of developping an app ( which isn't the case yet) before you start to advocate using it on a totally new territory.
How much credibility would you have if you were to say to backend developpers " swift is such a great language, you'll love coding with it on the server side", and they hear that iOS still can't include the stdlib because the language is still not stable enough ? I've tried, and the answer is none.
I find myself now thinking in Swift and coding in ES6... looks like SwiftJS is dead [0] but notice the Cocos2D folks just released a Swift-to-Android feature [1]. I really wouldn't mind Swift uber alles... someday.
