Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

faultlore.com

Post reply on HN
Print view View original

31–40 of 279 posts

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#31

Post by greyw »

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, ...)!

It's much better to just statically link your binaries (unfortunately many programs on GNU/Linux do not support this).

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.

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)

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#32

Post by Gankra »

forrestthewoods wrote: post #28
dnadoba wrote: post #23

Earlier quoted context omitted.

Yes, it is wrong. The article explains this quite well how you can trade performance and ABI stability.

The article doesn’t have any performance metrics. It mentions surprising performance cliffs but I couldn’t find details. It says there is a perf cost you can opt out of but doesn’t detail the cost or what you lose by opting out. It sure seems from the article that there are a lot of negative performance implications. Which totally be a price worth paying! But I would not agree that the article explains what that pric…

The biggest problem is that if you have a big """zero-cost-abstraction""" blob like iterator adaptors -- `Map>>>` -- and a single drop of Resilient Type is in there (i.e. MyType is resilient) then the whole thing gets polymorphically compiled and the compiler won't boil away any of the things that are supposed to be "zero cost".

How much you get burned by this kind of thing really depends on how you design APIs and where the hotspots are. Like if the big iterator blob is only ever for like 10 items, whatever. If the iterator blob is iterated inside the dylib where it's not resilient and can be inlined away, whatever.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#33

Post by taeric »

greyw wrote: post #31

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, ...)! It's much better to just statically link your binaries (unfortunately many…

Security updates, though?

I mean, you aren't wrong. But there were other advantages to dynamic linking.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#34

Post by jessermeyer »

taeric wrote: post #33
greyw wrote: post #31

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, ...)! It's much better to just statically link your binaries (unfortunately many…

Security updates, though? I mean, you aren't wrong. But there were other advantages to dynamic linking.

There is obviously a trade off here, but categorically speaking, new releases introduce new bugs and security exploits too.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#35

Post by Gigachad »

greyw wrote: post #31

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, ...)! It's much better to just statically link your binaries (unfortunately many…

Dynamic linking doesn't even really save disk space https://drewdevault.com/dynlib

The vast majority of libraries on your system are used by only one program. I'd imagine dynamic linking also freezes progress and improvements on libraries because it's extremely difficult to roll out changes without breaking packages that haven't been tested and updated for them.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#36

Post by Gigachad »

taeric wrote: post #33
greyw wrote: post #31

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, ...)! It's much better to just statically link your binaries (unfortunately many…

Security updates, though? I mean, you aren't wrong. But there were other advantages to dynamic linking.

You are going to see more security improvement by using Rust than the unlikely but possible chance of having your C library incidentally updated.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#37

Post by pornel »

taeric wrote: post #33
greyw wrote: post #31

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, ...)! It's much better to just statically link your binaries (unfortunately many…

Security updates, though? I mean, you aren't wrong. But there were other advantages to dynamic linking.

Dynamic linking is not the only way to deliver security fixes, just one particular, limited, C-oriented solution. Note that dynamic linking is also not sufficient to change C++ templates or C header-only libraries. It shifts all of the code replacement complexity from the OS (just replace a file) onto the language and library authors (ABI compat, fragile base classes, no inlining or generics).

Rust/Cargo gives you Cargo.lock (and more precise build plans if you want) that can be used to build a database of every binary that needs to be rebuilt to update a certain dependency. Distros could use it identify and update all affected packages. There are also caching solutions to avoid rebuilding everything. It's just something they didn't have to implement before, so naturally distros prefer all new languages to fit the old unbundled-C approach instead.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#38

Post by likeabbas »

alfor wrote: post #30
apatheticonion wrote: post #4

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. To what extent, if any, is Swift exclusive to Apple devices?

I think that Apple control where the language goes. That mean that things will serve other use cases only accidentally. fast.ai was very interested in Swift but dropped that project for that reason.

I wish fast.ai would have succeeded with Swift. The world desperately needs the ML community to move on from Python and towards a fast, statically typed language with truly concurrent multi threading.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#39

Post by malkia »

greyw wrote: post #31

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, ...)! It's much better to just statically link your binaries (unfortunately many…

You can't ship reasonable plugin for most of the popular content creation tools - be it audio, video effects, 3d modelling, etc. without support for dynamic/shared libs.

Okay, maybe you can - at the risk of performance cost - e.g. your out-of process plugin that need to move data in/out with a cost, and then it over complicates - because the plugin process might've died - how do you restart it, how do you get it back to state, etc. etc. You just don't have to solve this with .dll or .so

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#40

Post by Joker_vD »

greyw wrote: post #31

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, ...)! It's much better to just statically link your binaries (unfortunately many…

> Just keep the object files around and relink them against the updated version of the static libraries

You've just describe the gist of dynamic linking, you know that, right?

Post reply on HN