The memory management strategies in Rust and Swift are similar. The big performance hit in Swift would come in method dispatch where it’s following Objective C strategies which would result in indirect calls for object methods. This is possible in Rust (using Box(dyn trait)), but discouraged in critical paths in favor of either static dispatch by means of enums or reified calls through Rust generics. Swift has similar capabilities, of course, but with both languages, the best performance reqires consciously making choices in development.
> The big performance hit in Swift would come in method dispatch where it’s following Objective C strategies which would result in indirect calls for object methods.
While Swift can use Objective-C's message sending to communicate with Objective-C libraries, that isn't its primary dispatch mechanism. In the case of the service described in the article, it isn't even available (since it runs on Linux, which does not have an Objective-C runtime implementation).
Instead, like Rust, Swift's primary dispatch is static by default (either directly on types, or via reified generics), with dynamic dispatch possible via any (which is similar to Rust's dyn). Swift also has vtable-based dispatch when using subclassing, but again this is opt-in like any/dyn is.
Adding to what the sibling comment from airspeedswift said, there is not ever a need to use dynamic dispatch in Swift outside of iOS apps. Idiomatic apps will have many internal packages/targets that don't even import any Objective-C based libraries and can be compiled and run with just the swift toolchain. You can even inline all your frequent function calls. Idiomatic Swift also uses classes sparingly, and most are ideally declared final.
