I find it a bit sad that with all of the languages that already exist, Apple found it necessary to invent a completely new one -- and then make it proprietary. Why not use Ruby, or Python, or JavaScript -- or even Go, Rust, Clojure, or Scala? (Yes, I realize that the latter two run on the JVM, which would have been problematic in other ways.)
Heck, they could have bought RubyMotion and made Ruby the high-level language of choice for development.
I realize that Apple has a long tradition of NIH ("not invented here"), and in many cases, it suits them, and their users, quite well. But there are so many languages out there already that it seems like a waste for Apple to create a new one. Just the overhead of developing the language, nurturing its ecosystem, and ensuring compatibility seems like it'll cost more time and money than would have been necessary if they had gone with an existing language.
>Why not use Ruby, or Python, or JavaScript -- or even Go, Rust, Clojure, or Scala? (Yes, I realize that the latter two run on the JVM, which would have been problematic in other ways.) Heck, they could have bought RubyMotion and made Ruby the high-level language of choice for development.
Because OBVIOUSLY none of them solve the problems they wanted to solve (interoperabillity with Objective-C, fast, native, IDE integration, etc. Including RubyMotion which is a half-arsed implementation.
IDE integration for a new language? They wrote it themselves. Do you think it would have been harder to integrate an existing language?
Fast & native also also trivially solvable.
I don't know about interop with Objective-C, that's probably the hardest part from your list.
But complaining about IDE integration when they're also the creators of the IDE is... silly...
First, I like how you break apart the issues I raised (like "IDE integration") when I said that they wanted to solve ALL this problems at once.
So, even if just adding IDE integration for an existing language was easier than creating a new one, using an existing language wouldn't solve their other issues (e.g Obj-C interoperabillity with message passing, protocols, named parameters et al). And RubyMotion wouldn't permit all the optimizations they did, nor the kind of type safety they added.
>But complaining about IDE integration when they're also the creators of the IDE is... silly...
We're not talking about PyCharm level of IDE integration here. Not even about the current level of Obj-C/C++ integration XCode offers (for which they had to create LLVM tooling and LLDB to enable all the features they wanted to offer). It goes beyond that.
I see that you don't really understand what's needed for real IDE integration. Please, understand one of the main reasons of Apple creating Clang... (hint: because the GCC guys wouldn't take their patches to improve Objc-C & add facilities for IDE integration fast enough)
Clang was easier to integrate with an IDE than GCC, and I strongly believe (after seeing what apple showed yesterday) that swift integration is even simpler.
( They must have made a new LLVM front-end to embrace IDEs equally or better than Clang )
So no, it's not silly to try to design better to have a better integration with an IDE that you control too.
"Ruby, Python & co are well integrated into many third party IDEs" perhaps you're not familiar with the level of IDE integration we're talking about here.
Most (if not all) IDE's Ruby and Python integration is BS.
We're talking about real AST-based highlighting and suggestions, auto fixes, autocomplete for all APIs available (AND your own custom modules), integration with the debugger and the build system, and in Swift's case also integration with the REPL, LighTable-style live-variables and Brett-Victor-inspired live coding environment.
Apple likes to control the whole product as much as possible.
The iOS/OSX ecosystem is absolutely big enough to support an exclusive language (see Objective-C), and Apple chose to create a new language that matched their goals instead of adapt something they don't control and isn't ideal.
Makes perfect sense, and Swift was by far the most impactful announcement at WWDC.
Apple is a big, rich corporation. But in that campus there are still human developers.
Radical hypothesis: what if this started as a pet project, got the attention of more employees, then management (with or without convincing from said developers). Management sees the value in the project, and funds it officially. You know, like other big, rich corporations...such as Google.
When the project lead is one of the creators of LLVM (arguably the most fundamental low-level project in Apple after actual kernels), this sort of scenario is improbable.
Much more probable is that somebody asked top-developer Lattner for "a simpler language to compete with Java/Dalvik and C# with more casual developers" and he came up with Swift. The name itself is a message: "this thing is quick - quick to learn and quick to run, unlike VM-based stuff that must translate to Obj-C (fast to learn, slow to run) or Obj-C itself (fast to run, slow to learn)".
I would've voted for buying/licensing Xamarin instead; C#/F# would've given them everything including a lot of fresh programmers. On the other hand i'm happy they didn't as they would've tossed out Android and (at least for me) there is no alternative yet to the speed / power of development here.
Heck, they could have bought RubyMotion and made Ruby the high-level language of choice for development.
I realize that Apple has a long tradition of NIH ("not invented here"), and in many cases, it suits them, and their users, quite well. But there are so many languages out there already that it seems like a waste for Apple to create a new one. Just the overhead of developing the language, nurturing its ecosystem, and ensuring compatibility seems like it'll cost more time and money than would have been necessary if they had gone with an existing language.