Except it actually is incredibly slow, not fast. The only thing fast about it is the marketing, and that is mostly fast and loose.
I ran a ton of benchmarks for my performance book, and despite the fact that I didn't expect much, I was still surprised by just how badly it misses on the performance front.
As an example see how Kitura compares to other web frameworks in performance: https://www.techempower.com/benchmarks/#section=data-r16&hw=...
And Kitura actually implements the central HTTP parser in C. Porting that same code to Swift made it (that code, not Kitura) 10x slower.
As a second example, see JSON parsing. Putting Swift on top of NSJSONSerialization typically adds a 25x performance overhead. Yes, that's twenty-five. And NSJSONSerialization uses NSDictionary and friends to represent the parse result, which is already very, very slow. 25x on top of that is no mean feat.
Anyway, the good folk from Big Nerd Ranch decided the problem was the interop and decided to write a parser in pure Swift, called Freddy. It was a "success", as Freddy is only 8x slower than NSJSONSerialization.
Oh, and if you think Swift serialization fixes this: it doesn't. Still around an order of magnitude slower.
And I didn't even go into the role of the optimizer. Unoptimized code is much, much slower relatively speaking, sometimes 100x to 1000x (yes, that's a thousand) slower than optimized code. Note that the default debug mode in Xcode is unoptimized and that 1000x is the difference between 1 second and 20 minutes. And of course you don't get a diagnostic if an optimization is not applied.
The "Swift is fast" meme is pure Apple marketing at its most deceptive. It has never been true in the past and isn't true now.
As to safety: there is very little to no evidence that static typing actually increases safety, studies go either way and when there is a positive effect it is tiny. See also: http://blog.metaobject.com/2014/06/the-safyness-of-static-ty...
> [type inference falling over] usually such an expression is wrong
time swiftc too-complex.swift
too-complex.swift:1:49: error: expression was too complex to be solved in reasonable time; consider breaking up the expression into distinct sub-expressions
let a:[Int] = [1] + [2] + [3] + [4] + [5] + [6] + [7]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
real 1m20.639s
user 1m12.459s
sys 0m5.249s
This compiles fine if you reduce the number of elements. But that's of course just one of the most egregious examples. Overall, compile times are horrendously slow, again we are talking order(s) of magnitude, and that is with the horrible C compilation model and its ridiculous header files as a baseline.