This past week I’ve been reverse engineering the macOS IOMobileFramebuffer to find a way to disconnect displays in software for Lunar (<a href="https://lunar.fyi/" rel="nofollow">https://lunar.fyi/</a>).<p>And I kept stumbling upon these <i>witness tables</i> while debugging.<p>This led me to find this write-up and the much more interesting story behind it.<p>The end note was priceless ^_^<p><i>collapses</i>
Dynamic linking is in my opinion not that useful anymore in this day and age where the few MB of RAM and disk space you save is not worth the hassle. The amount of dynamic linking issues I encountered on GNU/Linux was insane (fuck libstdc++). Not even glibc manages to keep forward compatibility working (breaking memcpy, breaking DT_HASH, ...)!<p>It's much better to just statically link your binaries (unfortunately many programs on GNU/Linux do not support this).<p>Before the security guys come out the woods: No you don't need to rebuilt all programs linked against your dynamic library of choice. Just keep the object files around and relink them against the updated version of the static libraries. If now package manager just allowed differential binary updates (actually why is this trivial optimization not a common thing?) the overhead in terms of download size is not that of a big deal too.<p>The value you gain is immense: binaries just work (modulo linux ABI issues but they are doing quite a good job at keeping this interface stable)
Love the article.<p>In my mind I see the problem of dynamic linking in rust to have a bunch of overlap with the "I want this rust library to be exposed in my higher level GC'd language with minimal safety issues/tedious handmaintained bindings" problem.<p>My hunch is that the lack of expressiveness of the C ABI is holding back both. the thing I'd love to see some sort of "higher level than the C ABI" come out. And something like `wasm-bindgen`[0] to exist for more languages.<p>Here's a link to the rust "interopable_api" proposal! I don't understand all the implications, but it seems to be in the right direction <a href="https://github.com/rust-lang/rust/pull/105586">https://github.com/rust-lang/rust/pull/105586</a><p>[0]<a href="https://rustwasm.github.io/docs/wasm-bindgen/" rel="nofollow">https://rustwasm.github.io/docs/wasm-bindgen/</a>
Couldn't or wouldn't?<p>In some part, dynamic linking is one of the reasons for the travesty of dunces that's Docker and Kubernetes.<p>With static linking, most of that redundancy is not needed.
Aria is so good at putting things into accessible (and entertaining) words. One of the best at it I've ever seen (they're the same person who wrote the (in)famous "Learn Rust by writing Entirely Too Many Linked Lists", which is one of my favorite pieces of technical writing of all time)
this post makes me realize why swift is starting to look more and more bloated from an end-user pov. It was designed to be right from the beginning. instead of carefully backing off complex problems and slashing features to keep the design elegant, they just "went for it" at full speed.<p>History will tell if that was a good thing.
If I’m reading it right, reabstraction is about allowing you to make a protocol implementation more generic in future. If it’s implemented for String today, then if you change it to be implemented for all T in future then the dylib is still usable. The reabstraction thunks are checking that the type you’ve called it with is actually covered. So they’re not free.<p>The idea of calling polymorphically compiled functions with pointers to witness tables in extra arguments seems like something we could throw a simple JIT compiler at. A poly-function might have a list of available concrete implementations it could forward you to. You could, as a consumer of a dylib, for each call site on a poly function where you’re passing in a type known at compile time, initially write out a stub function, that the first time it runs, caches the result of this lookup and replaces the stub with something better. The stub would have a signature shaped optimally, the initial body of the stub would pad that out with the witness tables and code to initiate JIT using the poly function, and the JITed replacement would in the ideal case just be a jump instruction to a concrete implementation with a signature identical to the stub’s. Would that help?
What a great write up.<p>> Swift reserves a callee-preserved register for a method’s self argument (pointer) to make repeated calls faster. Cool?<p>Years ago (2000 I think), I remember Eliot Miranda explaining that the biggest optimization—-over and above all the jit stuff—in the VisualWorks Smalltalk VM basically came down to something very similar: very specific management of registers for the commonest of calling patterns.
Could someone help explain the difference between Rust ARC (Atomically Reference Counted) vs. Switch ARC (Automatic Reference Counting)?<p>Do the language designers intentionally chosen the same acronym to confuse us?
In 2020 I wanted to leverage the new apple silicon in my Rust app, so I needed to do some work in Swift, and maybe i was looking in the wrong spots - but the Swift community felt incredibly dead. Swift documentation is horrible, I asked for help in a few places online and got none. I eventually solved the problem by guessing to fill in the gaps of documentation. A very different experience than the rust community, which was extremely eager to help with every problem I had.
The TL;DR is: Swift strives for ABI stability, Rust does not.<p>There's also a driveby comment that C++ doesn't really support dynamic linking because of all the templates in its standard library, which is a weird statement to make.
A lot of people who are invested in the Apple ecosystem have been trying to present Swift as a general competitor to Rust, but no matter how many bullet points you list, as far as I can tell, it hasn't made any progress at all on that front, and I haven't been convinced that it will change to become closer to that any time soon, either.<p>As far as I can tell, there's really nothing wrong with Swift, and it probably has a lot to offer, but at some point someone's going to need to point out the obvious: basically nobody outside of the Apple ecosystem is considering using Swift for anything. That doesn't mean it's bad, but it's not a competitor to Rust today, and it's not trending in that direction.
I have heard great things about Swift but haven't spent a second looking into it because I assumed it's an Apple exclusive language - making it unsuitable for my use case of services deployed on Linux, developed from any OS.<p>To what extent, if any, is Swift exclusive to Apple devices?
My very vague understanding of Swift’s dynamic linking is that it works but comes with a huge performance penalty. To the point of it becoming unusable for high-performance apps.<p>Is that wrong?