Swift, first impressions

I did not expect Apple to announce a new programming language at WWDC this year, and judging by the room’s reaction on the stream, neither did most of the people who were there. Two weeks later I’ve read most of The Swift Programming Language on iBooks (it’s free, and it’s good) and written a few hundred lines in a playground, so here’s where I’ve ended up so far. Bear in mind this is a beta, and everything below could change.

The first thing I noticed is how familiar it feels if you come from C#. let and var with type inference, generics with constraints, closures with a short syntax, tuples, and an Optional type that’s basically Nullable<T> extended to everything. I’ve spent most of the last decade in C# (I’ve been an MVP since 2005, so I’m biased), and reading the book felt a lot like reading a list of things the C# team would add if they could start over without backward compatibility. Chris Lattner’s homepage says he started on it in July 2010, which means it’s been kept quiet inside Apple for almost four years. That’s impressive by itself.

Optionals are the part I like most. A String can never be nil, only a String? can, and you have to unwrap it with if let or ! before you can use it. It’s the thing I’ve wanted in C# for years: the compiler tells you where the nulls can be, instead of you finding out from a NullReferenceException in production logs. The ! is going to get abused (I can already see Objective-C APIs coming through as implicitly unwrapped String! everywhere), but the default is right.

Enums with associated values and an exhaustive switch are the other thing. If you’ve done any F# or Haskell this will be old news, but it’s the first time a mainstream language for app developers has made them this central. switch has no implicit fallthrough either, which I’ll take, since I’ve fixed a missing break bug in C more times than I’d like to admit (and C# made fallthrough a compile error, so C# folks won’t notice).

Integer overflow traps by default, and you opt into wrapping with &+ and friends. Good. I’d have liked C# to do that too, checked is off by default and nobody turns it on.

Then there are arrays. In this beta, a let array has a fixed length but you can still change its elements, and assigning an array to another variable doesn’t copy it until you change its length. So you can assign b = a, change b[0], and a changes too, unless you appended something first, in which case it doesn’t. The book has a whole section on this with unshare() and copy() methods. I read it three times. Dictionaries and strings are proper value types, arrays are this strange in-between thing, and it’s the one place where the language feels like a performance decision got ahead of the design. The developer forums are full of people complaining about it, so maybe it’ll change before 1.0.

The other things I’ve hit are what you’d expect from a beta. There’s no access control yet, no public or private, and Apple engineers have said on the developer forums that it’s coming. The editor crashes (SourceKit crashes, specifically, I’ve seen that dialog a dozen times). Compile errors are sometimes baffling. And you can’t ship Swift to the App Store until iOS 8 comes out in the fall, so for now it’s a language for playing with.

Playgrounds are a lot of fun, though. It’s not quite Bret Victor’s demo, but something like a REPL that shows you the value of every line as you type, and graphs a loop variable if you ask, is a nicer way to learn a language than anything Microsoft gives you right now. I spent an evening just poking at closures in one.

Will I write iOS apps in Swift? Probably, eventually. I’ve done mobile since Windows CE and I’ve never been able to love Objective-C’s brackets. But I’m going to wait for a version or two, and for the array business to be sorted out, before I’d put it in front of a team. And I’d like to see what Apple does with it outside of iOS and OS X. Right now it’s very much Apple’s language, for Apple’s platforms, and I don’t see that changing.