airspeedswift

You can choose to use either refcounting or unique ownership for your types. For most use cases, refcounted (+ copy-on-write) is the best choice and is the default, but the truetype interpreter made extensive use of non-refcounted types to achieve this performance.

I assure you, every inch of the interpreter code has been stared at by humans, a lot. TBH even the assembly generated by it has.

Python and LIT are used heavily to build and test the compiler, but that is only for building it, you do not need it to download and use the built toolchain. The python dependency is more about its use in LLDB.

The Swift toolchain includes LLDB, which relies on python for some debugging features. The compiler and runtime itself do not use python.

> e.g kotlin exceptions cant be caught from swift

FWIW the approach that swift-java takes in managing interop with Java (and potentially Kotlin) function calls means it is perfectly possible to to catch exceptions thrown by the JVM using wrappers that catch and rethrow them as Swift errors. So there would be a distinction here with bringing Swift calling into JVM-based code running on Android.

> 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.

Swift, Rust, and C++ all share the same underlying techniques for implementing zero-cost abstrations (primarily, fully-specialized generics). The distinction in Swift's case is that generics can also be executed without specialization (which is what allows generic methods to be called over a stable ABI boundary).

Swift and Rust also allow their protocols to be erased and dispatched dynamically (dyn in Rust, any in Swift). But in both languages that's more of a "when you need it" thing, generics are the preferred tool.

You can read about the trade-offs in the language proposal here: https://github.com/swiftlang/swift-evolution/blob/main/propo...

In particular:

> Even with the introduction of typed throws into Swift, the existing (untyped) throws remains the better default error-handling mechanism for most Swift code. The section "When to use typed throws" describes the circumstances in which typed throws should be used.

you might find https://www.swift.org/documentation/articles/zero-to-swift-n... useful

Been there since 2.0. You can combine it with pattern matching to do some fun stuff: https://gist.github.com/airspeedswift/6e0c037ad5dd1b763d353f...