He had me at closures. Nomadic chunks of code that show up when they’re needed.

Quick note: This episode is heavy geek.

A few years past Apple was looking for something to fill a few minutes in their presentation to their faithful developers. “Let’s tell them about Swift”, someone high up decided. I was watching that presentation, and at first I was all like, “Another language? This will be a fiasco.” Apple has a mixed (and mostly bad with one great success) record when it comes to languages. A few minutes in, I was intrigued. By the end, I was sold.

Swift built on the work of great designers of other languages, and managed to bring (most of) the best of untyped languages with (most of) the best of strongly-typed languages. In my heart, I’m a strongly-typed guy, but I’ve been using javascript long enough to appreciate its flexibility.

But there’s one place Swift went that no other language has ever tread. Nil. One of the most common problems in software is when you expect something to the there, but for whatever unexpected reason, nothing is there. This is literally the cause of every blue screen of death you have ever seen.

In Swift, when you say that variable x will be of a particular type, right from the get-go you have to decide if x can ever be nil. If you allow that x can be nil, then every time you use x you have to take the potential that it is nil into account. No getting around it. If you say that x can never be nil, then the compiler will not allow you to create any condition that x is nil.

You can, of course, punch the compiler in the face and say you know goddam well that by then x will not be nil. But, awesomely, you don’t have to be all aggro. You can be totally graceful and say, “if x is not nil, then let’s have some fun.”

Swift has many other features created with one purpose: Make the costly mistakes commonly made with other languages impossible. One of the motivators of this language was a potentially awful security flaw on iPhone a few year back, caused by a stupid missing curly brace.

The Swift compiler is almost spooky. I’m not going to go into its almost-magic ability to resolve generics, but dang.

I do have a quibble: If one is focussing a language on security and preventing bad programming patterns, I would like to see the end of “break” and “continue”. We all learned long ago how terrible “goto” is; it’s time to recognize goto’s buck-toothed kin. (In the iPhone security problem above, goto was part of the problem. I was stunned that any code from my company included that instruction.) I once sat through a long discussion on the WebKit boards while they argued about how to define constants to handle exceptional cases, when the exceptional cases themselves could have been eliminated by banishing “break”.

Programmers out there: any time you want to type “break”, there is a better answer. If you can’t find that answer, it’s time to grow. Seriously. Outside of case statements, there is no time “break” is the right answer. EVER. (Swift eliminated break in case statements for you.)

Maybe I’ll fork the Swift open source and create hard-ass Swift. The same as Swift, but without the goto’s. Or maybe I’ll just challenge my peers to embrace the spirit of Swift, and write good code.

I program in four languages day in and day out, and a few others now and then. Give me Swift.