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

121–130 of 279 posts

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

#121

Post by saagarjha »

jasmer wrote: post #58
mr_00ff00 wrote: post #44

Earlier quoted context omitted.

I know this might be opening a can of worms, but technically doesn’t Swift do reference counting? Which is faster than “mark and sweep” GC but will never compare to manual management (like C/C++ and rust ownership) I assume that’s the big reason.

That's definitely the elephant in the room. And the fact that it does not have clean and easy C integration. If you could do direct memory stuff and control the ARC stuff, and easily integrate with C ... ... and the docs were clean, and you could easily use something other than XCode ... Then Swift would be huge. It's a neat language but it's just not designed to go beyond Mac. The entire C++ world would move away in…

Swift has better C integration than Rust does.

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

#122

Post by saagarjha »

mr_00ff00 wrote: post #90
pkulak wrote: post #73

Earlier quoted context omitted.

If reference counting was faster, Java would do it. It’s better for UIs and lower latency, but a modern, generational GC can beat C in throughput (because allocations get a lot faster).

Genuine question, but if that were true then why does High Frequency Trading and Performance critical applications use C if GCs can beat it?

HFT often does use languages that run on GCs.

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

#123

Post by Jach »

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.

I like SDL2's approach to enable both: https://old.reddit.com/r/linux_gaming/comments/1upn39/sdl2_a... A game can statically link the library, but the user can with an environmental variable override the functions to point at their dynamic library instead. Very useful especially with games as you can then keep them running on new platforms or fix certain bugs even though the developers have long since disappeared or moved on.

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

#124

Post by saagarjha »

puffoflogic wrote: post #27

[flagged]

I am honestly curious what kind of content you must be consuming to come to that sort of conclusion. Like, is there a secret “anti-dynamic linking league” somewhere who pushes people to think it’s the literal spawn of Satan?

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

#125

Post by charcircuit »

rektide wrote: post #87
Gigachad wrote: post #35

Earlier quoted context omitted.

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.

We run hundreds of processes on big nodes at work & we absolutely would save hella hella memory & have way better cache utilization if we could share the massive massive massive reams of code each process duplicates for itself. Static linking is basically like running Electron. You take a wonderful multi-machine capable environment then use it to run a single thing, exacerbating the size of what should be minor overh…

>We run hundreds of processes on big nodes at work & we absolutely would save hella hella memory & have way better cache utilization if we could share the massive massive massive reams of code each process duplicates for itself.

Assuming those hundreds are mostly duplicates why can't they all share their entire code section?

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

#126

Post by saagarjha »

ip26 wrote: post #86
ridiculous_fish wrote: post #49

Earlier quoted context omitted.

Apple uses dynamic linking to enable its OSes to evolve. Apple's libraries talk to daemons using IPC protocols such as XPC or MIG; if those libraries were statically linked, the daemons would have to support old protocols forever. And when Apple changes the appearance of its UI, they want all apps to get the changes immediately, and not wait for the apps to be recompiled. For example, way back I implemented window re…

As a late inductee to their ecosystem, I think this strategy is paying off for them. Not sure if this angle was ever pitched as part of the dynamic/static holy wars, aside from security patches.

It’s the main reason why dynamic linking is popular. It’s just that the people on Hacker News often write client software for Linux rather than having to deal with ABI compatibility :)

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

#127

Post by mr_00ff00 »

zaphar wrote: post #115
mr_00ff00 wrote: post #90

Earlier quoted context omitted.

Genuine question, but if that were true then why does High Frequency Trading and Performance critical applications use C if GCs can beat it?

The two biggest languages I'm aware of in that space are Java and C++. I don't think I've heard of any shop using C. Java seems to be keeping up with C++ there as far as I know. Do you have evidence to the contrary?

Yeah I guess I used C and C++ interchangeably, but I believe C++ is the language of HFT.

Do you have evidence to the contrary?

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

#128

Post by darknavi »

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…

Steam encourages devs to dynamically link SDL2 so that they can patch it for them [0]. Pretty neat IMO.

Sorry for the terrible link, Google+ is deleted now but luckily a bot mirror the post to reddit.

[0]: https://www.reddit.com/r/linux_gaming/comments/1upn39/commen...

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

#129

Post by wongarsu »

lamontcg wrote: post #108
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…

If you don't care about saving disk space then just ship all your dynamic libraries with your binaries.

That pretty much sums up what everyone does on Windows. Lots of things are linked dynamically, but apart from the C/C++ runtime library and the OS libraries you just ship all those DLLs with your software.

But this works because in Windows each software is installed in it's own folder, and the search path for dynamic linking starts in the binary's folder. That way you can just dump everything in your installation folder without worrying about comparability with other software. In a Unix or Linux this is much harder to achieve. Sure, you can install into your own folder in /opt and add a wrapper script to load libraries from there, but it's hardly idiomatic.

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

#130

Post by comex »

Gigachad wrote: post #35
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.

That post keeps being linked in these discussions but it's highly misleading.

> Do your installed programs share dynamic libraries?

> Findings: not really

The posted findings actually show that common libraries ranging from libc to libX11 are used by high-hundreds to thousands of binaries. The fact that there are also a lot of not-widely-shared dynamic libraries doesn't seem particularly significant.

> Wouldn't statically linked executables be huge?

> Findings: not really

> On average, dynamically linked executables use only 4.6% of the symbols on offer from their dependencies. A good linker will remove unused symbols.

This analysis is completely wrong because it ignores the effect of transitive dependencies. If all exported symbols are independent and don't depend on anything else, then using 4.6% of the symbols means the linker can strip the library down to 4.6% of the size. Simple libraries like libc or libm are pretty close to that ideal. But for more complex libraries, the exported symbols are just the entry points for a deep nest of interlinked functions, and often a single symbol will transitively depend on a large fraction of the library.

Post reply on HN