Swift at Apple: Migrating the TrueType Hinting Interpreter

[edit: <swearing> I don’t know why every comment I write turns into a gigantic wall of text]

The swift folk have been really working on supporting non-Apple platform developers, but I suspect it will never truly escape the “language for Apple software” label.

It also incurs costs not present in rust, first group, object lifetime management:

• refcounting as the common object lifetime guard (essentially all objects are Arc). I think this does make it easier to for new folk to grasp as it better matches how object lifetimes work in other languages, but inherently has costs rust does not.
• The compiler is free to do heap allocations if necessary. It does do this automagically so can incur surprise allocation costs.
• following from the prior point: core data types are immutable, this is achieved by CoW semantics, however if the compiler cannot prove non-escaping of a value you start hitting (atomic) single owner checks.

These are really nice features from an ease of use PoV, but the cost can be significant (refcounting and CoW tests get slow when subject to multithreaded contention).

The other source of accidental overhead is the strict design goal of ABI stability. This is an extremely important feature, but the costs go from relatively minor (offsets into fields across package/library boundaries become indirect - non-fragile types), to high: generic interfaces default to a stable abi, which in a practical sense lowers to something approximately equivalent to rust’s dyn trait. If your library does not have ABI constraints it can be somewhat irksome to find and fix cases where the codegen is unnecessarily pessimistic for the purpose of abi stability.

Now those costs would rule swift out of the embedded space, but to deal with that there is embedded swift which essentially means that the super dynamic or runtime heavy behaviours become unavailable but beyond that high level hand waving I don’t know specifics.

Now for personal gripes:

• the lack of parens around if/switch/while control expressions, a choice for which I blame Brendan Eich (somewhat light heartedly)
• the “cute” trailing closure syntax - it results in calls that look like standard blocks, but return statements in the closure are returning from the closure, not the block. This is a visible error if you attempt continue/break but not if you simply return.
• I do love the things that type inference based on the knuth-bendix completion algorithm makes possible, but the perennial “this expression took too long to type check” compilation failure is still frustrating even if increasingly uncommon, and even when knowing the cause (KBC is fundamentally undecidable). For a simple expression this can often be resolved easily, but if one of the expressions is a closure/lambda it becomes miserable.

I also dislike the kinds of applications that come from SwiftUI but that’s not really a language issue, and I don’t write ui code either, e.g. it’s “only” an issue from the user end, not from a developer PoV.

TLDR: While there are a bunch of features in swift that I really like, there are also a bunch of trade offs that make it often slower than Rust programs (see this article for examples where they needed to not use the default style of swift code in order to reach the target perf).

The “killer” feature is ABI stability even at the high level language constructs, but that’s only just started to be something (I think) rust is trying to address, but it requires a willingness to have the kind of indirection (at least, if not implicit allocation) that is counter to the rust design pronciples.

How does that compare to other languages where you statically link its runtime and stdlib (say, go, rust)? Is Swift stdlib really that heavy? Or is it just in comparison to Apple platforms where you link dynamically?