How Swift achieved dynamic linking where Rust couldn't (2019)

Re:How Swift achieved dynamic linking where Rust couldn't (2... by millstone on Saturday February 20, 2021 @02:24PM (#26206996)

Rust is certainly made simpler by not sweating ABI stability. But the main advantage of dynamic linking is to enable yesterday's app to run on tomorrow's OS (and vice-versa). It's why your apps keep working when you update your phone.

Without a dynamic linking story, Rust is just not viable for writing UIKit, Android's frameworks, etc. Which is OK, it's a reasonable choice, but it limits Rust's scope.

[ Parent | on HN ]

Re:How Swift achieved dynamic linking where Rust couldn't (2... by dralley on Saturday February 20, 2021 @03:11PM (#26207471)

Zig is in a really good position here. Its featureset sticks closer to C, and being able to automatically generate C headers from Zig code and automatically consume C headers from Zig code is really convenient.

[ Parent | on HN ]

Re:How Swift achieved dynamic linking where Rust couldn't (2... by pjmlp on Saturday February 20, 2021 @03:17PM (#26207533)

Not until it sorts out its use-after-free story.

[ Parent | on HN ]

Re:How Swift achieved dynamic linking where Rust couldn't (2... by millstone on Saturday February 20, 2021 @03:19PM (#26207555)

Does Zig really solve this problem? For example, if I add a field to a Zig struct, can existing code still use the struct without needing to be recompiled?

[ Parent | on HN ]

Re:How Swift achieved dynamic linking where Rust couldn't (2... by dralley on Saturday February 20, 2021 @03:26PM (#26207619)

No, but what I'm saying is, it makes dynamic linking a lot easier in general than Rust does.

[ Parent | on HN ]