> A reimplementation of Calendar in Swift is 1.5x to 18x as fast as the C one (calling from Swift in various synthetic benchmarks like creation, date calculation). These sorts of statements in the industry always make me ask, "So did you guys make something terribly slow first, and then bring performance back close to where it originally was?" I'm not sure if the current Calendar app was ported to Swift, was original…
In this case, the answer is basically, "yes". Objective-C is a neat language and really powerful in terms of flexibility and extensibility. But it gets that by essentially dynamically typed. It's Smalltalk duct taped onto C.
Dynamically typed languages are much slower unless you do lots of very powerful JIT magic, and even then they still tend to be quite a bit slower than most statically typed compiled languages.
Building Swift on top of an Objective-C core library makes a lot of sense in terms of getting Swift adoption when Swift was new. But in terms of performance, it's sort of like building a concrete bunker on top of a straw hut. You really want the bottom of your stack to be the faster, statically typed language. Then you can layer dynamic scripting languages on top for the users who want it.