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

151–160 of 279 posts

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

#151

Post by Kranar »

andyonthewings wrote: post #60
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…

It's a common argument of computers getting powerful so we don't need to care that much for performance and/or efficiency regarding to cpu/memory/storage etc. In some limited cases the argument is valid but most of the time it's not. First of all while maybe desktops and mobile phones are more powerful now, but we're getting more and more lower spec devices, like smart watches. Even when smart watches will be powerfu…

If what you care about is efficiency, then stick to static linking. Dynamic linking inhibits so many optimizations.

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

#152

Post by dusted »

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…

I too wonder if it's worth the effort to ship around a trillion versions of different libs (with their trillions of different versions of dependency libs)^n.

One neat thing about it is that we get to override functionality easily, either by replacing entire binaries (such as we do with glide-wrappers to get our 3Dfx fix on modern windows machines) or by using LD_PRELOAD to load hooking SOs to fixup data in old binaries as they are used.

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

#154

Post by physicsguy »

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…

The best argument for dynamic linking IMO is not the runtime distribution but the cost of linking everything into a static binary while developing.

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

#155

Post by alexvoda »

lamontcg wrote: post #143
wongarsu wrote: post #129

Earlier quoted context omitted.

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 fol…

I did it for 10+ years at my last job, you need a build system that hammers on everything really hard to set the rpath on everything, you shouldn't need wrappers. It definitely isn't idiomatic though.

What is the philosophy behind why it's not done like this Linux? Also, what about Nix?

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

#156

Post by vrnvu »

tubs wrote: post #21
grantjpowell wrote: post #15

Love the article. 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. 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 someth…

So, COM?

Sorry, does anyone mind to explain/reference what COM is?

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

#157

Post by hutattedonmyarm »

brundolf wrote: post #91
myko wrote: post #75

Earlier quoted context omitted.

What's stopping you from using it on Linux, or your platform of choice? It seems to be supported well enough, and Vapor is a decent toolkit for building a webapp with it.

My understanding is that it's got second-class Linux support, for now. What happens when Apple loses interest? What about Windows? I don't get a sense of commitment from them outside of their own platforms, and that doesn't make me want to commit to learning or starting major projects in the language (outside of their platforms). If I can't have faith my project's foundation will continue to be solid, then I don't wa…

Foundation (Swift's stdlib so to speak) is being rewritten as OSS [0] which will unify it between Linux and macOS. Right now, they use a different implementation on each platform

[0]: https://www.swift.org/blog/future-of-foundation/

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

#158

Post by imron »

Shorel wrote: post #146

Couldn't or wouldn't? In some part, dynamic linking is one of the reasons for the travesty of dunces that's Docker and Kubernetes. With static linking, most of that redundancy is not needed.

Docker and kubernetes excel in a world of static binaries.

Gotta love those 5mb bare images.

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

#159

Post by imron »

vrnvu wrote: post #156
tubs wrote: post #21

Earlier quoted context omitted.

So, COM?

Sorry, does anyone mind to explain/reference what COM is?

Component object model. It’s a windows thing from the 90’s that still permeates the lower levels of windows programming.

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

#160

Post by zdimension »

vrnvu wrote: post #156
tubs wrote: post #21

Earlier quoted context omitted.

So, COM?

Sorry, does anyone mind to explain/reference what COM is?

The result of Microsoft developers in the 90s drunkenly making up an object model on top of C with the goal of it being cross-language and cross-platform (in theory). The idea being that you can define an interface and implement it in any language and consume it in any language. A good idea in theory. In practice, DLL hell often made the experience unpleasant. A big part of Windows's APIs are COM-based. For historical reasons it's also used at the core of a few macOS system components, hence the grandparent comment
Post reply on HN