> It should scale from App/UI language down to system language.
Did I miss something where Apple or the Swift team said anything about writing a kernel in Swift? They wanted to make it fast enough for performance-critical situations, yes, but there are plenty of those in userspace -- and I haven't found Obj-C's inability to perform in those situations to be an asset.
> It should inter-op with existing Foundation and Cocoa, but still bring its own wide reaching standard library, adding a lot of duplication.
This is missing the forest for the trees. Bringing Swift-native Foundation APIs into the standard library means they're available on non-Mac platforms, which is huge. I'm also not sure what alternative would be preferable -- should it _not_ interop with Foundation/Cocoa, and totally fragment the ecosystem? Or should _not_ reimplement them with native calls, so that it inherits the performance penalty of objc_msgSend?
> It is functional, object-oriented and protocol oriented all at the same time.
Apple describes Swift as protocol-oriented. It's flexible enough to support other paradigms, but I don't see how that's a liability, and I haven't seen Apple claim "Swift is an FP language".
> It wants to be strongly typed, but at the same time so convenient in type inference, that it falls over its own feet while trying to grasp simple expressions, and they become too complex to manage. By design.
[citation needed]
This complaint is so vague as to be impossible to address, except to say that I haven't managed to come across a case of it yet. An example would really help make the case.
> It is compiled and static, but emphasized the REPL and playground face that makes it want to look like a great scripting solution. Which it isn't.
Again, I haven't heard any claim that "Swift is a scripting language". Sure, it's not, but neither is Objective-C, so... I'm not really sure what the complaint is here?
> It seems to have been driven by the needs of the compiler and the gaps that needed to be filled for the static analyzer. Those seem to have been super-charged instead of catering to app developer's actual needs: efficient, hassle free, productive (iOS) App development.
This sounds like a complaint about strong typing and static dispatch in general. Yes, you have to code more carefully, but the flipside is that a huge number of errors that crop up at runtime in Objective-C become compile-time errors in Swift. I'd much rather bang my head against the compiler for a while before I ship than have reams of undebuggable crash logs pour in.
> It is meant offer progressive disclosure and be simple, to be used in playgrounds and learning. At the same time learning and reading through the Swift book and standard library is more akin to mastering C++. It is quite unforgiving, harsh, and complex.
That's true, but that's also kind of a big part of why playgrounds exist. So again, what's the complaint? Is the fact that playgrounds make the language more accessible a problem somehow?
Also, the only way I can view Objective-C as "simple" is by ignoring the C underpinnings and looking only at the relatively thin layer of classes and message passing on top. For somebody coming to coding with fresh eyes, both Swift and Objective-C are going to have a learning curve; the difference is that with Swift you don't have to pick up K&R first.