> - It would be a big deal if Rust did have a safe dynamic linking ABI. Someone should do it. That's the main point I'm making. I don't think deflecting by saying "but C is no safer" is super interesting.

I think we all agree that it would be a huge deal.

> - So long as this problem isn't fixed, the upside of using Rust to replace a lot of the load bearing stuff in an OS is much lower than it should be to justify the effort. This point is debatable for sure, but your arguments don't address it.

As you point out, this is the debatable part, and I'm not sure I get your justification here.

▲

pizlonator 3 hours ago | parent [-]

This might end up being the forcing function (quoting myself from another reply in this discussion):

> It can't be that replacing 20 C/C++ shared objects with 20 Rust shared objects results in 20 copies of the Rust standard library and other dependencies that those Rust libraries pull in. But, today, that is what happens. For some situations, this is too much of a memory usage regression to be tolerable.

If memory was cheap, then maybe you could say, "who cares".

Unfortunately memory isn't cheap these days

▲

staticassertion 2 hours ago | parent [-]

How much overhead is that? Also, why would that have much overhead? Things deduplicate in memory.

▲

rlpb 2 hours ago | parent [-]

Your apt update would still be huge though. When the dependency changes (eg. a security update) you’d be downloading rebuilds of 20 apps. For the update of a key library, you’d be downloading your entire distribution again. Every time.

	▲	staticassertion an hour ago \| parent [-]
		Oh, well yeah, statically linked binaries have that downside. I guess I don't think that's a big deal, but I could maybe imagine on some devices that are heavily constrained that it could be? IDK. Compression is insanely effective.