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

81–90 of 279 posts

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

#81

Post by rektide »

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 is the shit! It's so undersold. Static linking has been convenient & simple, but it gives up so much awesomeness.

On consumer systems, memory pressure is real, and being able to have quarter your program be effectively free is enormously helpful. Cache hits also go way up, which can be even more vital.

Server side, it depends. If you just run a db server and a monolith, it indeed doesnt matter. But if I look at the hosts we run at my work, if you look at many clusters, they're big nodes and they're running hundreds of processes. If we could get back decent double digit percent of memory that would be great. If caches would get more effective that'd be super. We're leaving a ton on the table because nothing is shared.

There's similar works to win back basic obvious performance happening in a number of places. Composefs has shown up on HN a couple times, trying to let containers effectively share files & page-cache.

Will I deny that dynamic linming has brought pain? No. But I think it's important to recognize that this is a fallback position. If we were better about not breaking conpatibility, not introducing changes, this would be less of an issue. If we had better software testing that could help us detect & see incompatibility faults as they arise, if we could canary test a new software Bill-of-Materials & have some early indicators, we might have, a decade ago, not collectively decided to give up & give in to "binaries just work".

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

#82

Post by techdragon »

myko wrote: post #75
brundolf wrote: post #67

Earlier quoted context omitted.

It's a bummer because I feel like I'd really like Swift if I felt it were a real, durable cross-platform language to spend time learning and using. Some of the trade-offs it makes seem really nice But I don't feel like Swift on non-Apple platforms will ever be more than a hobby for the Apple org

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.

Speaking as someone with similar feelings… “Well enough” and “decent” are not how I would describe something I’m thinking of investing significant mental time and effort learning and familiarisation building on. I’ve done the basic tutorials and generally like the language ergonomics, it’s not bad, and I kinda like it for the little bit of Apple platform dev I’ve done with it. But it’s basically a different language on any non Apple platform.

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

#84

Post by sweetjuly »

alin23 wrote: post #13

This past week I’ve been reverse engineering the macOS IOMobileFramebuffer to find a way to disconnect displays in software for Lunar ( https://lunar.fyi/ ). And I kept stumbling upon these witness tables while debugging. This led me to find this write-up and the much more interesting story behind it. The end note was priceless ^_^ collapses

I feel your pain, reverse engineering Swift is such a nightmare. I don't know if Ida handles it better but both Ghidra and Binja produce entirely inscrutable disassembly.

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

#85

Post by Joker_vD »

greyw wrote: post #42
Joker_vD wrote: post #40

Earlier quoted context omitted.

> 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?

The end user gets a single statically linked binary which is what matters. The quoted sentence refers to distro maintainers providing new binaries.

Ah, so I (the programmer) build object files, send them to the distro maintainers, they link them with their specific versions of the libraries, ands send the resulting executable binary to me/other users.

...that's remote dynamic linking, only with (potentially) human intervention in the loop. I kinda see how it would have worked better if the distro maintainers cared about package quality and speedy updates but they don't (bacause they physically can't, it's way too much effort for way to few people).

Look, I don't argue that dynamic linking has zero problems — heavens know how much I've struggled with glibc but that's mostly because glibc is bloody insane. The whole slew of GNU dynamic-linking-related extensions to ELF is insane, now that I think of it.

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

#86

Post by ip26 »

ridiculous_fish wrote: post #49
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…

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.

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

#87

Post by rektide »

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.

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 overhead.

As a Linux user, there's like 30 dependencies used by basically half of what I run. If you click in to the article & look at the first chart, it shows this clearly: it tapers down quickly yes but so what? What actually matters? There are a good solid chunk of core libraries used en volume. You dont save much disk space, yes. But many libraries are used by many-hundreds of consumers. Thats where the pain is, that's the loss, that's where you are burning memory space again and again and again with every process you load, and worse, is the cache you are contesting for no reason. You could share that. You should. Giving it up is only because someone has decided it's too hard & too difficult to try,.. and sometimes they are right. But most Linux distros have been working through & managing it & doing ok for years.

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

#88

Post by galangalalgol »

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…

What do you mean about rust being too specific for most things? It seems like a fairly obvious choic for c++ replacement in a new project, the issue is large c++ codebases already exist, and that migration is painful in my experience. Autocxx type support is still largely missing or in work, diplomat seems reasonable, but I haven't had an opportunity to use it for something real yet.

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

#89

Post by wilg »

jchw wrote: post #43

A lot of people who are invested in the Apple ecosystem have been trying to present Swift as a general competitor to Rust, but no matter how many bullet points you list, as far as I can tell, it hasn't made any progress at all on that front, and I haven't been convinced that it will change to become closer to that any time soon, either. As far as I can tell, there's really nothing wrong with Swift, and it probably ha…

This is all very hand-wavey. Are you just describing a chicken-and-egg scenario?

Also, Swift probably can compete with Rust, especially when they finish adding Rust-style lifetimes. But the real advantage of Swift is it has a much more "high-level" feel than Rust – it's much more familiar to use than Rust by virtue of having classes and things. Swift also doesn't instantly force you into weeds of dealing with memory management complexity. I think I'm going to enjoy the "drop into manual memory management for hot paths" approach Swift is taking.

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

#90

Post by mr_00ff00 »

pkulak wrote: post #73
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.

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?
Post reply on HN