Benchmarks like this miss the point of what it is to write production software code. The only people who care about this style of benchmark are people with very

Benchmarks like this miss the point of what it is to write production software code. The only people who care about this style of benchmark are people with very specialised use cases and academics (and their students), the latter of which are trying to prove something that is easy to prove, but doesn't really tell us anything of practical use. For most purposes, a user of your software is not going to feel the difference between 0.0006 seconds and 0.06 seconds. One is 100x faster, so is "better", but no user will care. The stuff that is really expensive (3D graphics, etc.) that users care about are being handed off into custom APIs that are highly optimised and hardware acceleration anyway. What's more important for most programmers when choosing a language is not "how fast is it for this code to run?", but "how quickly can I ship code?" Code in the app store next quarter is going to beat code you never get shipped, every single time. Not long ago I had a project I thought would be perfect for Haskell. I don't know Haskell but I am a very experienced Ruby-ist. I thought about using the project as a means to learn Haskell but wanted the code shipped within a month. I did it in Ruby. It's probably slower, it's perhaps not as elegant as a Haskell solution. But it's shipped. And that therefore beats the Haskell solution which does not exist. Swift appears to have modern features that mean many programmers will feel more comfortable developing applications using it, many of whom would have struggled with Obj-C. In that sense, it's going to beat Objective C for performance in the only benchmark that matters commercially: the one that gets ideas into user's hands the quickest. If you think the rate of development so far has been fast, well, just watch. It's about to get mental. I don't expect an academic to understand that, nor would I expect most junior/undergrad devs, and I can see in some special cases you would want to think about optimisation (in which case turn that little piece of code into C and link it in), but in the real World, that's how coding works.