How Swift Achieved Dynamic Linking Where Rust Couldn't A look at what's required to ship a dynamically linked system interface, the most interesting parts of Swift's stabilized ABI, and their incredibly ambitious resilient library evolution system https://gankra.github.io/blah/swift-abi/
-
Show this thread
-
Replying to @Gankra_
Nice writeup! I should mention that Rust tried in its early days to do witness tables (“type descriptors”/“tydescs”). I wrote a lot of that code. Ironically, one of the big reasons we ripped it out was because of code bloat.
1 reply 0 retweets 27 likes -
IIRC switching to monomorphization actually *reduced* code size by quite a bit. Though the biggest reason was just performance: we couldn’t get type descriptor overhead below 20% of the program runtime or so, which was unacceptable.
4 replies 0 retweets 23 likes -
My final attempt to save tydescs was actually to compress addref/release/etc code into a generic interpreter that could parse an abstract description of the type. This reduced code size/compile time a lot but brought the overhead of tydescs to ~30% IIRC (could be misremembering).
3 replies 0 retweets 3 likes -
Replying to @pcwalton
were you using a hybrid monomorph/polymorph approach like swift does? that seems to smooth over the pain in a lot of places.
2 replies 0 retweets 1 like -
Replying to @Gankra_
My takeaway at the time—that I still think I believe?—is that JITs are the only really elegant solution here.
1 reply 0 retweets 0 likes -
There was a series of notes from academia I can’t find offhand that I consulted around the time. It also came to the conclusion that JITs are probably the best solution, though acknowledged tons of tradeoffs.
1 reply 0 retweets 0 likes
(BTW Swift’s approach is called “intensional type analysis” in the literature)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.