Am I the only one who finds it odd that while pushing two high level but performant languages (Objective-C and Swift) Apple wrote their Swift compiler in C++?
Not in the short term. C++ is a very pragmatic language for implementing compilers, since it has good performance characteristics and allows higher-level programming idioms than C.
That said, we do expect Swift to a better language than C++ in a number of ways, so why don't we implement the compiler itself in Swift? There are a couple of reasons that bootstrapping is not a good idea, at least in the short term:
This complicates bringup of the compiler, because you have to move both the compiled language and the compiler at the same time as the language evolves. We want the language evolution and direction to be driven by general purpose programming challenges, not by the specific needs of compiler hackers. The urge to "scratch our own itch" might be too great. That said, we are writing the runtime library in Swift itself. We may also decide to rewrite the compiler in Swift sometime in the distant future when the language settles down. At that point, it may be a good opportunity to revisit previous (internal to the compiler) design decisions, and we do expect and hope Swift to be a great language for doing many things, including implementing compilers."
By using C++ they could ramp up the compiler much faster and rely all improvements done to LLVM.
Eventually if the language succeeds in the market at large, they can decide to bootstrap it.
Although I am a fan of bootstrapping, I also see a good value to expend development resources elsewhere until a language reaches wider adoption.
Saying it was "quite a pain" is the understatement of the year.
The solution we had, though, is Servo. It being developed alongside as well meant we had another significant, non-compiler project, which guided us out of that trap.
And of course it is not possible to write a Swift compiler in Swift before the language exists.
So no, not odd at all. Quite logical actually.
No, but you can do a self-hosting port after you have a first rudimentary compiler. Many compilers have been built like this. Some did it early in language development with a purpouse built one-off bootstrapping compiler, some did it after the language was somewhat stable (eg Go).
ObWP: https://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29
Aside from the value of maintaining LLVM as a shared codebase, the concern was that writing a compiler in Swift could bias early language design tradeoffs towards decisions that would make it easier to write a compiler at the expense of the larger universe of potential applications.
From a language design point of view, the things needed to get a language to the point where it could successfully and efficiently compile itself would skew or re-order priorities in a much different fashion than if they were to focus on building and iterating on an applications and systems language.
tl;dr: LLVM and Clang and their assorted toolsets do quite a bit of valuable work; reinventing that to serve the language they're building is a feedback loop is a downside that also removes some upside from the equation, too.
That being said, C++ is probably a better choice, because dynamic dispatch sucks and there's better platform support.
Yes other languages have LLVM bindings, but they aren't as comprehensive as actually linking to the LLVM C++ API.
Source: Have written a (toy-ish) compiler with LLVM