A thought on Swift and C++

I’ve been coding in Swift on some personal projects in recent months, and I generally like it. I’ve also, over the years, done quite a bit of C++, most heavily in the late ’90s and early ’00s. I find some interesting parallels and contrasts between the two languages in those respective periods.

At that time, C++ was no longer as new as Swift is now, but it was an exciting time for the language. The standard was evolving, and compilers were implementing these new capabilities, and the community was figuring out how to effectively use them. Modern C++ style, idiom, and practice were emerging, such as a move away from runtime class polymorphism and towards generic algorithms and concrete types. People were figuring out what the C++ toolkit gave us, and how to write programs in C++, not in some other language using C++ syntax. This is in many ways how the world of Swift feels to me today: as a solid language where idioms and preferences are still rapidly being worked out.

At their core, the two languages also share much the same nature: a mix of programming paradigms, not purely object-oriented nor purely anything else, pulled together in a developer-focused, pragmatic design, all balanced against a commitment to legacy compatibility (C source compatibility in one case, Objective-C interoperability in the other).

The contrast is, of course, that C++ is and was implemented by a variety of compilers, while Swift has one implementation maintained by the same folks who maintain the language specification. There are upsides and downsides to that. Specifically in terms of the language evolution, though, there is one main thing which comes to mind.

As those new C++ standards, techniques, and libraries were being worked out, many of us were stuck on certain compilers where we could not enjoy what was going on. Where by “certain compilers” I am referring to Microsoft Visual C++.

Microsoft’s compiler is great these days, as far as I’ve tried it. But at the time, many things (such as new template techniques) didn’t work right on MSVC, or at least not without a lot of workarounds. Cross-platform libraries were full of #ifdefs. Worse, Windows-only code often became dependent on nonstandard aspects of MSVC, leaving developers stuck on old versions as Microsoft improved their implementation.

Swift has no such problem. The standard, the (only) compiler, and even the primary IDE, are controlled by Apple. And that toolchain has built-in fix suggestions and migration tools which makes the pain of syntax changes that much more bearable, at least for smaller projects. And Apple doesn’t care about backwards compatibility; they sometimes break things just for fun (like the cover art in my iTunes music library, for example).

There are certainly downsides to having only one implementation and authority, but now we get to watch another multiparadigm, programmer-focused language evolve, with a huge amount of investment behind it, but this time no fragmentation, an interesting contrast.