Comment by sandGorgon

6 years ago

Supporting both polymorphic and monomorphic compilation helped Swift a lot, but I think the key difference was ultimately just that Apple had a more significant motivation than Mozilla to pursue dynamic linking and way more resources to throw at this very hard problem.

Interesting stand.

15 comments

sandGorgon

Reply
saagarjha  6 years ago

All of macOS's system libraries are dynamically linked, so there's just no way Swift could be used in the OS if it didn't do this right.

  • masklinn  6 years ago

    They're C libraries, there's very few languages which can't dynamically link to C. The essay is about Swift dynamically linking to Swift directly (not through a C ABI as e.g. C++ or Rust would).

  • sandGorgon  6 years ago

    The last part of the line reads (rather politically incorrectly) that Apple has more talent available to solve this problem.

    • zozbot234  6 years ago

      Or they were just willing to accept a significant increase in language complexity, to deal with things that Rust just punts on by basically expecting you to stick to #[repr(C)] at your preferred dylib boundary. (Though, potentially, that #[repr(C)] could become e.g. #[repr(SomeArbitraryStableABI)], and there have been proposals to this effect.) And they did this precisely because of that perception that Swift "wouldn't be usable" otherwise.

    • atq2119  6 years ago

      Resources != Talent, and the line talked about resources, not talent.

      It's pretty obvious that Apple can throw more money at the problem than Mozilla can, if they choose to do so. That means they can buy more developers to work the problem, which is bound to be helpful whether those developers are particularly talented or not.

      There's really nothing politically incorrect about that.