Think: How many iOS apps are frontends to a server API? And how many of those APIs are running on Linux servers? Swift on Linux means ~all the code for a client-server iOS app can be written in the same language.

Golang is a pragmatic crowd. Go into #go-nuts on freenode, you'll notice that discussion rarely deviates from solving problems. Many links to the go playground. Go, from the beginning, shaped their community in this way. Consciously? Who knows. But the community turned out the way it did and I believe that's a result of their start.

Haskell is a computer scientist crowd. People write in haskell because they enjoy the functional paradigm and haskell is a purely functional language. Discussion on freenode? Very dense. People are expected to grasp topics easily and the community initially gives everyone the benefit of the doubt that they are capable of understanding it until they ask for more help.

When I look at swift, the only thought I have is that it is the new iOS language. I don't believe they'll be able to deviate from that. I don't see myself making iOS apps, so I don't see myself every writing a single line of the language. When I first looked at swift, my impression was that it was a wierd and somewhat-functional language that had a few unique things. Maybe I would have taken an interest in it. But at this point, I don't want to have to wade through a bunch of iOS specific questions to get what I need. I don't want to have to deal with being a beta tester for their linux implementations. I don't want to use the language when I'm probably going to be using it in a vastly different way than the rest of the community is. My interests are going to be second class.

It's not necessarily set in stone, but I think it is. In a world where there's a new language every day, I just don't see why I'd go with swift.

Avoiding this "fracture" could have been a powerful argument for it, along with maintaining control (the nodes iojs situation could not have inspired confidence, though that was not due to interoperability from what I know)

I would have definitely participated in the hate if I had seen that thread, all I can saw now is: bravo Apple! More of this please!

Sometimes companies change their minds this way, like how Microsoft changed its mind on the banning of DVDs for Xbox, even though they never "officially" said they would do that before the announcement of the Xbox One, but it was strongly "rumored" they would do that. I'm sure that's what they intended, but the outrage was too big to let it be.

It's hard to realize most of the performance benefits when everything you're interacting with requires objc_msgsend or uses NSArray / NSDictionary.

As well, it's far less 'scripty' than Obj-c. The type system in swift really leaves something to be desired in terms of typing types. The point of Obj-C was kind of to avoid writing the kinds of apps where a great type system would really shine, swift lets you build those kind of apps, but in my opinion most of the time we shouldn't be building them.

Your project probably doesn't need 1,000 developers on it who need solid interfaces and type checking to make sure that everything is going according to the UML diagram. It probably needs 2 or 3 developers who talk to each other, add asserts to their code, and a type system thats a little forgiving.

ObjC is a language that has everything you really really need, and left out the 1 thing you kinda wanted in exchange for leaving out the thousand 1 little things that everyone else wanted too. Like for example exceptions, sure they're there, but it's not idiomatic and when you program without them you realize what a crappy idea they were in practice. In day to day coding NSError is 1000x better than exceptions.

The switch when dealing with a combination of C/C++ and Objective-C source was not really a problem. But trying to interface a C++ library into a Swift application is less than a fun experience.

Personally, while the language is fresh and seems pretty good (it has some great additions), I still prefer Objective-C. I guess I'm waiting for better integration with existing libraries.

But that's not surprising given its ecosystem; as others have mentioned, language success has less to do about its theoretical benefits and more to do about what environments it allows the developer access to. Javascript is the case-in-point; I think few people would argue it is a well-designed language, but if you want to do web development, you're going to need at least a basic understanding of it, so it maintains brutal popularity.

React Native is a godsend.

I haven't either, but I haven't used it a lot so I can't give a final verdict on it. But I'm the kind of person that enjoys C++ (well, especially after C++11, feels like a new language and I'm slowly becoming a C++ fanboy), and I guess all those new system languages like Swift and Rust are supposed to fill the void for people that don't like the existing system languages available, so maybe it's not for me.

You can be sure Apple will remain the exclusive ruler of what goes into Swift.

https://android-review.googlesource.com/#/c/150214/

Looks like there is someone at Google working on lambda support.

Swift is like Rust in that it's intended to be fast, "safer", and compiles to LLVM bytecode. Also, Swift and Rust both use Option types for error reporting rather than exceptions or error codes.

In the same sense that Rust is a way to leave behind old C++ baggage, Swift is a way to leave behind old ObjC baggage such as header files, null pointer errors, and lack of real namespaces.

I'm a bit naive about the environments languages have to run in... but if we have a web app framework in Swift, Servers in swift (as mentioned in comments above), and iOS in swift, doesn't that make Swift a JS replacement too?