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++?
Lattner directly addresses this in a FAQ in the repository[1]
"Do you plan to rewrite the Swift compiler in Swift?
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."
Mind, are you not worried at all that it may have taught you a lot... about how to make a language for writing compilers in? (paraphrasing Chris Lattner)
That is indeed a concern, I agree with Chris here.
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.
> of course it is not possible to write a Swift compiler in Swift before the language exists
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).
Some people I know previously asked this question to one of the Swift developers. I believe the reasoning was along the lines of (very liberally paraphrased/interpreted): Even aside from the problem of bootstrapping the compiler's compilation to start, performant compilation on C++ is a very mature and well-explored problem space. C++ already compiles on a ton of systems, and maintaining a C++-to-Swift(bootstrap compiler)-to-Swift(final compiler) compilation process is added complexity and invites repeated work.
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.
I believe I saw Lattner once describe a self-hosting compiler for Swift as an anti-goal, at least before the design had stabilized.
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.
Objective-C bridges to and from Swift easily, so it would be easily to incrementally replace Objective-C code with Swift code. Since C++ doesn't interact with Swift at all, it would either have to be wrapped in C/Objective-C, or the entire compiler would need to be rewritten at once.
That being said, C++ is probably a better choice, because dynamic dispatch sucks and there's better platform support.
I'm glad they didn't write it in Objective-C, as this would probably make compilation on Linux much harder (I have no idea what the state of Linux support for Objective-C is). As for writing it in Swift itself, that's not possible until Swift is sufficiently stable and with enough library support. Which it may or may not have now, but certainly didn't have when they started ;)
Linux support for ObjC is great on the compiler side (GCC supports the full language), but none of the core libraries are available. You can get some stuff (NSString, NSDictionary and so on) through GNUstep, but last I checked it was an uphill battle to be truly productive with ObjC on Linux.
GCC doesn't support the full language anymore, since the stuff that Apple added after finishing the migration to Clang hasn't been ported to GCC (e.g. generics and array/dictionary literals) and there doesn't appear to be anyone interested in doing so.
