It’s now been almost exactly one year since Apple Music was announced, so I
thought I’d give a bit of a retrospective of that time.
I inadvertently kicked up a big stink two months ago by pointing out how slow
Swift was, which was version 1.1 at the time. Apple has since responded
with a new beta version of Xcode which includes a shiny new version of Swift,
version 1.2. Since it promised to:
… produce binaries that run considerably faster, and new optimizations
deliver even better Release build performance.
I thought it would be prudent to re-run my tests and see just how much Swift
has improved, if at all.
Much and more has been written about Apple’s new programming language, Swift.
I even did a talk about it at Yow: Connected 2014. If you saw me there,
you’d know that I’m not the biggest fan of Swift. I think the rollout of it has
been an absolute disaster: the compiler is a shambles,
the language design is inconsistent in places and it’s stupidly difficult
to get working in libraries, particularly if you want to support iOS 7. Surely
though, at the very least its performance would be all right. After all, it’s
designed to be more static and do more checking at compile-time and is meant
to be made with the LLVM optimiser in mind…
Let’s talk about performance in Swift, then.
Just as it is with coding standards, everyone thinks they have the answers when it comes to hiring new people. I’m under no such delusions. I don’t pretend that this method will work for everyone. It won’t. This is simply the mechanism that I used to hire the team I currently work with. The team in question has turned out rather spectacularly, thanks in no small part to the effectiveness of this method. If you or your business is looking to hire more developers, I’d encourage you to consider this method, or at the very least, consider simplifying your hiring process to just the bare essentials that tell you what you’re really looking for.