They came to it through a pretty pragmatic process. They made a list of candidate languages (they haven't discussed what the list was beyond "all the obvious candidates were represented") and assigned existing parts of the codebase to a few engineers asking them to reimplement the feature in the candidate languages. The team found they enjoyed working with Swift the most, and Swift's good support for OOP fit the object model of a web browser very well.
The C++ interop story for Swift isn't the most clear cut, though. You're forced to use Apple's fork of llvm (meaning no GNU or mainline clang support) and there are issues tracking the current blockers[0]. Along with other related issues under the "swift" tag[1]. I don't think this was necessarily a bad technical decision, but from a lock-in and practicality perspective it seems flawed.
Sure but that is already another criteria set, similar to how Carbon is also being developed, and not a plain "doesn't do OOP", because Java OOP is not the only flavour in town, which many folks conflate OOP with.
Not only does it predate the language by a few decades, there is enough type systems variants to chose from.
I haven't worked with it myself but my understanding is that Swift's C++ interop has improved a lot recently and is continuing to be improved. Apple has a huge C++ codebase so they are incentivized to make Swift work well with it
polling enjoyment is superbly pragmatic! this is a volunteer project that depends critically on the developers continuing to enjoy working on it. once you get past the first cut of "is this a reasonably mature language with a lot of community support behind it that compiles to fast native executables", enjoyment is one of the best ways you can choose between the various candidates. you can pretty much assume that rust/c++/swift/go/kotlin/etc all have the cross-platform support and libraries you will need.
