>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.
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.